The scope of this Protection Profile Module (PP-Module) is to describe the security functionality of a virtual private network (VPN)
client in terms of [CC] and to define functional and assurance requirements for such
products. This PP-Module is intended for use with the following Base-PPs:
Protection Profile for General Purpose Operating Systems (GPOS PP), Version 4.2.1
Protection Profile for Mobile Device Fundamentals (MDF PP), Version 3.2
Protection Profile for Application Software (App PP), Version 1.4
Protection Profile for Mobile Device Management (MDM PP), Version 4.0
These Base-PPs are all valid because a VPN client may be a specific type of stand-alone software
application or a built-in component of an operating system (OS), whether desktop or mobile. Regardless of
which Base-PP is claimed, the VPN client functionality defined by this PP-Module will rely on the Base-PP.
Sections 5.1, 5.2, and 5.3 of this PP-Module describe the relevant functionality for each Base-PP,
including specific selections, assignments, or inclusion of optional requirements that must be made as
needed to support the VPN client functionality.
1.2 Terms
The following sections list Common Criteria and technology terms used in this document.
1.2.1 Common Criteria Terms
Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)
A Protection Profile developed by
international technical communities and approved by multiple schemes.
Common Criteria (CC)
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory
Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)
Common Evaluation Methodology for Information Technology Security Evaluation.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
Extended Package (EP)
A deprecated document form for collecting SFRs that implement a particular protocol, technology,
or functionality. See Functional Packages.
Functional Package (FP)
A document that collects SFRs for a particular protocol, technology,
or functionality.
Operational Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)
An implementation-independent set of security requirements for a category of products.
A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)
An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs.
Security Assurance Requirement (SAR)
A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)
A requirement for security enforcement by the TOE.
Security Target (ST)
A set of implementation-dependent security requirements for a specific product.
Target of Evaluation (TOE)
The product under evaluation.
TOE Security Functionality (TSF)
The security functionality of the product under evaluation.
TOE Summary Specification (TSS)
A description of how a TOE satisfies the SFRs in an ST.
1.2.2 Technical Terms
Administrator
A user that has administrative privilege to configure the TOE in privileged
mode.
Authorized
An entity granted access privileges to an object, system or system entity.
Critical Security Parameter (CSP)
Security related information, e.g. secret and private cryptographic keys, and
authentication data such as passwords and PINs, whose disclosure or
modification can compromise the security of a cryptographic module.
Entropy Source
This cryptographic function provides a seed for a random number generator
by accumulating the outputs from one or more noise sources. The
functionality includes a measure of the minimum work required to guess a
given output and tests to ensure that the noise sources are operating
properly.
IT Environment
Hardware and software that are outside the TOE boundary that support the
TOE functionality and security policy.
Private Network
A network that is protected from access by unauthorized users or entities.
Privileged Mode
A TOE operational mode that allows a user to perform functions that require
IT Environment administrator privileges.
Public Network
A network that is visible to all users and entities and does not protect against
unauthorized access (e.g. internet).
Threat Agent
An entity that tries to harm an information system through destruction,
disclosure, modification of data, or denial of service.
Unauthorized User
An entity (device or user) who has not been authorized by an authorized
administrator to access the TOE or private network.
Unprivileged Mode
A TOE operational mode that only provides VPN client functions for the VPN
Client user.
VPN Client
The TOE; allows remote users to use client computers to establish an
encrypted IPsec tunnel across an unprotected public network to a private
network.
VPN Client User
A user operating the TOE in unprivileged mode.
VPN Gateway
A component that performs encryption and decryption of IP packets as they
cross the boundary between a private network and a public network.
1.3 Compliant Targets of Evaluation
The TOE defined by this PP-Module is the VPN client, a software application that runs on a physical or
virtual host platform, used to establish a secure IPsec connection between that host platform and a
remote system. The VPN client is intended to be located outside or inside of a private network, and
establishes a secure tunnel to an IPsec peer. For the purposes of this PP-Module, IPsec peers are defined
as:
An IPsec-capable network device (supporting IPsec for the purposes of management)
The tunnel provides confidentiality, integrity, and data authentication for information that travels across
a less trusted (sometimes public) network. All VPN clients that comply with this document will support
IPsec.
This PP-Module extends the GPOS PP when the VPN client is installed on an OS discussed
in that PP (e.g., Windows, Mac OS, Linux). This PP-Module extends the MDF PP when the VPN client is
installed on a self-contained mobile device that is bundled with an OS (e.g. Android,
BlackBerry OS, iOS, Windows Mobile). This PP-Module extends the App PP when the VPN client is
provided by a third party and is a standalone application that is not a bundled part of an OS
or mobile device. This PP-Module extends the MDM PP when the VPN Client is included with
MDM Server software that is used for centralized deployment and administration of enterprise mobile
device policies.
As a PP-Module of any of these PPs, it is expected that the content of this PP-Module and the chosen
Base-PP be appropriately combined in the context of each product-specific ST. This PP-Module has been specifically defined such that there should be no difficulty or ambiguity in doing so.
When this PP-Module is used, conformant TOEs are obligated to implement the functionality required in
the claimed Base-PP with the additional functionality defined in this PP-Module in response to the
threat environment discussed in this PP-Module.
1.3.1 TOE Boundary
The TOE defined by this PP-Module is purely a software solution executing on a platform (some sort of
OS running on hardware). Depending on the Base-PP claimed as part of the TOE, the
platform may also be part of the TOE or it may be an environmental component that the TOE vendor has
no control over. Regardless of whether the platform itself is within the scope of the evaluation, the VPN
client itself will rely on the platform for its execution domain and proper usage. The vendor is expected
to provide sufficient installation and configuration instructions to identify an Operational Environment (OE)
with the necessary features and to provide instructions for how to configure it correctly.
The PP-Module contains requirements that must be met by the TOE. Depending on the Base-PP that is
claimed, there may be some variation in the applicable requirements. This is because a given Base-PP
may include one or more requirements that the VPN client can inherit but are not shared between each
possible Base-PP.
This is somewhat different than other PPs, but addresses most implementations of VPN clients where
some part of the functionality of the IPsec tunnel is provided by the platform. In terms of the
cryptographic primitives (random bit generation, encryption and decryption, key generation, etc.) it is
actually desirable that a well-tested implementation in the platform is used rather than trying to
implement these functions in each client.
Requirements that can be satisfied by either the TOE or the platform are identified in Section 5 by text
such as “The [selection: TSF, TOE platform] shall…” The ST author will make the appropriate selection
based on where that element is implemented. It is allowable for some elements in a component to be
implemented by the TOE, while other elements in that same component be implemented by the
platform (requirements on the usage of X.509 certificates is an example of where this might be the case,
where using the information contained in the certificates and the implementation of revocation
checking may be done by the TOE, but storage and protection of the certificates may be done by the
platform). Note that in the cases where this PP-Module is used to extend the GPOS PP or MDF PP, the
TOE includes both the VPN client and the platform. In this case, it is appropriate to indicate that the TOE
satisfies this requirement. However, the ST author should make it clear, for each of these components,
which are implemented by the VPN client portion of the TOE versus the platform portion.
A Supporting Document (SD) accompanies this PP-Module and contains guidance for how to evaluate
the requirements defined by the PP-Module, expressed as Evaluation Activities (EAs). EAs will differ
based on where the function that meets the requirement is implemented. In most cases, requirements
implemented by the platform will require that the evaluator examine documents pertaining to the
platform (generally the ST), while requirements implemented by the TOE may require examination of
the TSS, examination of the Operational Guidance, or execution of evaluator testing. For
requirements implemented by the platform, there may also be requirements where the evaluator must
examine the interfaces used by the TOE to access these functions on the platform. This ensures that the
functionality being invoked to satisfy the requirements of this PP-Module is the same functionality that
was evaluated.
Given the degree of coupling between a VPN client and its underlying platform, it is expected that the
client will be tested on each platform claimed in the ST. In cases where the platforms are simply
different versions of the same OS (provided by the same platform vendor), an equivalency
argument may be made in lieu of testing on each version. The argument would have to demonstrate
that the client interacts in exactly the same way with the versions of the OS (i.e., the same APIs are used
with the same parameters, the network stack is modified with exactly the same kernel modules). The
evaluator uses the operational guidance to configure the TOE and underlying platform.
A TOE that conforms to this PP-Module will implement the Internet Engineering Task Force (IETF)
Internet Protocol Security (IPsec) Security Architecture for the Internet Protocol, RFC 4301, as well as
the IPsec Encapsulating Security Payload (ESP) protocol. IPsec ESP is specified in RFC 2406 and RFC 4303.
The IPsec VPN client will support ESP in either tunnel mode, transport mode, or both modes.
The IPsec VPN client will use the Internet Key Exchange (IKE)v1 protocol, IKEv2, or both. IKEv1 is
implemented as defined in RFCs 2407, 2408, 2409, 4109, and IKEv2 is implemented as specified in RFC
7296 and 4307 to authenticate
and establish session keys with the VPN entities. The IKEv2 implementation also requires mandatory support for network address translation (NAT)
traversal as specified in section 2.23 of RFC 7296.
In order to show that the TSF implements the RFCs correctly, the evaluator will perform EAs
documented in the SD that accompanies this PP-Module. In future versions of this
PP-Module, EAs may be modified or new ones may be introduced that cover more aspects of RFC compliance
than is currently described in this publication.
The IPsec VPN client enables encryption of all information that flows between itself and its IPsec peer.
The VPN client serves as an endpoint for an IPsec VPN connection and performs a number of
cryptographic functions related to establishing and maintaining that connection. If the cryptography
used to perform endpoint authentication, generate keys, and encrypt information is sufficiently robust
and the implementation has no critical design mistakes, an adversary will be unable to exhaust the
encryption key space to obtain the data. Compliance with IPsec standards, use of a properly seeded
Random Bit Generator (RBG), and secure authentication factors will ensure that access to the
transmitted information cannot be obtained with less work than a full exhaust of the key space. Any
plaintext secret and private keys or other cryptographic security parameters will be zeroized when no
longer in use to prevent disclosure of security critical data.
1.4 Use Cases
A VPN client allows users on the TOE platform to establish secure IPsec communications, providing
confidentiality, integrity, and protection of data, across a less trusted network in order to secure data in
transit. This PP-Module defines three use cases for VPN clients. A conformant TOE will implement one or
more of the use cases specified below:
[USE CASE 1] TOE to VPN Gateway
A VPN client allows users on the TOE platform to establish an encrypted IPsec tunnel across a
less trusted, often unprotected, public network to a private network (see Figure 1). In this case,
the TOE provides encryption and decryption of network packets as they leave and arrive on the VPN client’s
underlying platform. IP packets crossing from the private network to the public network will be
encrypted if their destination is a remote access VPN client supporting the same VPN policy as
the source network.
The TOE is responsible for encrypting the packets that are intended to be received by the target
on the private network and then encapsulating these packets in a way that allows the VPN
gateway to securely receive them and forward them to their final destination.
A VPN client may additionally or alternatively allow a client computer to connect directly to
another computer running a VPN client (see Figure 2). In this case, the functionality of the VPN
client is to connect directly to another endpoint system in order to facilitate communications
directly to that system.
IPsec transport mode is used for end-to-end communications. In this use case, the content of
the packet data (payload) is encrypted but the original IP header is preserved. Inherent to this
use case, when two peers are communicating directly, is the disclosure of the
source and destination of the packets. Users should take into consideration any security risks
associated with this disclosure when architecting their networks in line with this use case.
Similar to Use Case 2 above, a VPN client TOE can also be used to establish a secure connection
to an IPsec-capable network device using IPsec, similar to how SSH can be used. In this case,
where a network device is being managed remotely over an IPsec connection, the network
device itself must contain IPsec functionality to act as the peer for the connection (see Figure 3).
While this will behave functionally the same way as the scenario described by Use Case 2, the
user of the TOE in Use Case 3 is a network administrator who is assumed to have administrative
access to the network device they are connecting to.
Regardless of the specific usage of the TOE, the focus of the Security Functional Requirements (SFRs) in this PP-Module
is on the following fundamental aspects of a VPN client:
Authentication of the IPsec peer
Cryptographic protection of data in transit
Implementation of services
A VPN client can establish VPN connectivity either to a VPN gateway with traffic bound for a remote
endpoint in the private network that is protected by the VPN gateway (Use Case 1), to a VPN client peer
residing on a remote endpoint in the same network as the TOE (Use Case 2), or to a network device
with IPsec capability for the purposes of managing that device (Use Case 3). In the first case, the entire
IP packet is encapsulated and a new header is applied so that the gateway can route the packet to its
intended destination. This is known as tunnel mode. In the latter two cases, the original IP header is
preserved and only the payload is encrypted. This is known as transport mode.
Beyond the implementation differences specified by these use cases, the remaining security
functionality is expected to be implemented by all VPN clients, regardless of whether it supports one or
more of the use cases. Regardless of the intended use case, VPN endpoints authenticate each other to
ensure they are communicating with an authorized external IT entity. Authentication of IPsec peers is
performed as part of the Internet Key Exchange (IKE) negotiation. The IKE negotiation uses a pre-existing
public key infrastructure for authentication and can optionally use a pre-shared key. When IKE
completes, an IPsec tunnel secured with Encapsulating Security Payload (ESP) is established.
It is assumed that the VPN client is implemented properly and contains no critical design mistakes. The
VPN client relies on the system or device on which it is installed for its proper execution. The vendor is
required to provide configuration guidance (AGD_PRE, AGD_OPE) to correctly install and administer the
client machine and the TOE for every OE supported.
2 Conformance Claims
Conformance Statement
This PP-Module inherits exact conformance as required from the specified Base-PPs and as defined
in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated
May 2017).
PP-Module for Wireless Local Area Network (WLAN) Client, Version 1.0
CC Conformance Claims
This PP-Module is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version
3.1, Revision 5 [CC] when App PP, GPOS PP, or MDF PP is the Base-PP.
This PP-Module is conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version
3.1, Revision 5 [CC] when MDM PP is the Base-PP.
PP Claim
This PP-Module does not claim conformance to any PP.
Package Claim
This PP-Module does not claim conformance to any packages.
3 Security Problem Description
The security problem is described in terms of the threats that the TOE is expected to address,
assumptions about its OE, and any organizational security policies that the TOE is
expected to enforce.
This PP-Module is written to address the situation in which a user accesses a private network (e.g. the
user’s office network) or terminal endpoint (e.g. a network device) using a less trusted network (such as
a public Wi-Fi network or local area network). Protection of network packets is desired as they traverse
a public network. To protect the data in-transit from disclosure and modification, a VPN is created to
establish secure communications. The VPN client provides one end of the secure VPN tunnel and
performs encryption and decryption of network packets in accordance with a VPN security policy
negotiated between the VPN client (TOE) and its IPsec peer.
The proper installation and configuration of the VPN client is critical to its correct operation such that
proper handling of the TOE by an administrator is also addressed.
Note that as a PP-Module, all threats, assumptions, and organizational security policies (OSPs) defined in the Base-PP will also apply to a
TOE unless otherwise specified, depending on which of the Base-PPs it extends. The SFRs
defined in this PP-Module will mitigate the threats that are defined in the PP-Module but
may also mitigate some threats defined in the Base-PPs in more comprehensive detail due to the
specific capabilities provided by a VPN client.
3.1 Threats
The following threats defined in this PP-Module extend the threats defined by the Base-PPs.
T.UNAUTHORIZED_ACCESS
This PP-Module does not include requirements that can protect against an insider threat. Authorized
users are not considered hostile or malicious and are trusted to follow appropriate guidance. Only
authorized personnel should have access to the system or device that contains the IPsec VPN client.
Therefore, the primary threat agents are the unauthorized entities that try to gain access to the
protected network (in cases where tunnel mode is used) or to plaintext data that traverses the
public network (regardless of whether transport mode or tunnel mode is used).
The endpoint of the network communication can be both geographically and logically distant from
the TOE, and can pass through a variety of other systems. These intermediate systems may be under
the control of the adversary, and offer an opportunity for communications over the network to be
compromised.
Plaintext communication over the network may allow critical data (such as passwords, configuration
settings, and user data) to be read or manipulated directly by a malicious user or process on intermediate systems, leading to
a compromise of the TOE or to the secured environmental systems that the TOE is being used to
facilitate communications with. IPsec can be used to provide protection for this communication;
however, there are numerous options that can be implemented for the protocol to be compliant to the
protocol specification listed in the RFC. Some of these options can have negative impacts on the
security of the connection. For instance, using a weak encryption algorithm (even one that is
allowed by the RFC, such as DES) can allow an adversary to read and even manipulate the data on
the encrypted channel, thus circumventing countermeasures in place to prevent such attacks.
Further, if the protocol is implemented with little-used or non-standard options, it may be compliant
with the protocol specification but will not be able to interact with other diverse equipment that is
typically found in large enterprises.
Even though the communication path is protected, there is a possibility that the IPsec peer could be
tricked into thinking that a malicious third-party user or system is the TOE. For instance, a
middleman could intercept a connection request to the TOE, and respond to the request as if it were
the TOE. In a similar manner, the TOE could also be tricked into thinking that it is establishing
communications with a legitimate IPsec peer when in fact it is not. An attacker could also mount a
malicious man-in-the-middle-type of attack, in which an intermediate system is compromised, and
the traffic is proxied, examined, and modified by this system. This attack can even be mounted via
encrypted communication channels if appropriate countermeasures are not applied. These attacks
are, in part, enabled by a malicious attacker capturing network traffic (for instance, an
authentication session) and “playing back” that traffic in order to fool an endpoint into thinking it
was communicating with a legitimate remote entity.
T.TSF_CONFIGURATION
Configuring VPN tunnels is a complex and time-consuming process, and prone to errors if the
interface for doing so is not well-specified or well-behaved. The inability or failure of an ignorant or careless administrator to configure certain aspects
of the interface may also lead to the mis-specification of the desired communications policy or use
of cryptography that may be desired or required for a particular site. This may result in unintended
weak or plaintext communications while the user thinks that their data are being protected. Other
aspects of configuring the TOE or using its security mechanisms (for example, the update process)
may also result in a reduction in the trustworthiness of the VPN client.
T.USER_DATA_REUSE
Data traversing the TOE could inadvertently be sent to a different user as a consequence of a poorly-designed TOE; since these data may be
sensitive, this may cause a compromise that is unacceptable. The specific threat that must be
addressed concerns user data that is retained by the TOE in the course of processing network traffic
that could be inadvertently re-used in sending network traffic to a user other than that intended by
the sender of the original network traffic.
T.TSF_FAILURE
Security mechanisms of the TOE generally build up from a primitive set of mechanisms (e.g.,
memory management, privileged modes of process execution) to more complex sets of
mechanisms. Failure of the primitive mechanisms could lead to a compromise in more complex
mechanisms, resulting in a compromise of the TSF.
3.2 Assumptions
These assumptions are made on the Operational Environment (OE) in order to be able to ensure that the
security functionality specified in the PP-Module can be provided by the TOE.
If the TOE is placed in an OE that does not meet these assumptions, the TOE may no longer be able to
provide all of its security functionality.
A.NO_TOE_BYPASS
Information cannot flow onto the network to which the VPN client's host is connected without
passing through the TOE.
A.PHYSICAL
Physical security, commensurate with the value of the TOE and the data it contains, is assumed to
be provided by the environment.
A.TRUSTED_CONFIG
Personnel configuring the TOE and its OE will follow the applicable security
configuration guidance.
3.3 Organizational Security Policies
An organization deploying the TOE is
expected to satisfy the organizational security policy listed below in addition to all
organizational security policies defined by the claimed Base-PP.
This document does not define any additional OSPs.
4 Security Objectives
4.1 Security Objectives for the TOE
O.AUTHENTICATION
To address the issues associated with unauthorized disclosure of information in transit, a compliant
TOE’s authentication ability (IPsec) will allow the TSF to establish VPN connectivity with a remote
VPN gateway or peer and ensure that any such connection attempt is both authenticated and
authorized.
To address the issues associated with unauthorized disclosure of information in transit, a compliant
TOE will implement cryptographic capabilities. These capabilities are intended to maintain
confidentiality and allow for detection and modification of data that is transmitted outside of the
TOE.
The TOE will provide sufficient measures to ensure it is operating in a known state. At minimum this
includes management functionality to allow the security functionality to be configured and self-test
functionality that allows it to assert its own integrity. It may also include auditing functionality that
can be used to determine the operational behavior of the TOE.
To address the issues associated with unauthorized disclosure of information at rest, a compliant
TOE will ensure that non-persistent data is purged when no longer needed. The TSF may also
implement measures to protect against the disclosure of stored cryptographic keys and data
through implementation of protected storage and secure erasure methods. The TOE may optionally
also enforce split-tunneling prevention to ensure that data in transit cannot be disclosed
inadvertently outside of the IPsec tunnel and prohibit transmission of packets through a connection until certain conditions are met.
4.2 Security Objectives for the Operational Environment
The OE of the TOE implements technical and procedural measures to assist the TOE in correctly providing its security functionality (which is defined by the security objectives for the TOE).
The security objectives for the OE consist of a set of statements describing the goals that the OE should achieve.
This section defines the security objectives that are to be addressed by the IT domain or by non-technical or procedural means.
The assumptions identified in Section 3 are incorporated as security objectives for the environment.
OE.NO_TOE_BYPASS
Information cannot flow onto the network to which the VPN client’s host is connected without
passing through the TOE.
OE.PHYSICAL
Physical security, commensurate with the value of the TOE and the data it contains, is assumed to
be provided by the environment.
OE.TRUSTED_CONFIG
Personnel configuring the TOE and its OE will follow the applicable security
configuration guidance.
4.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organizational
security policies map to the security objectives.
The TOE mitigates the threat of inadequate configuration by providing a management
interface that allows all security-relevant functionality to be configured.
The TOE mitigates the threat of data reuse by ensuring that persistently stored data is
protected from unauthorized access, non-persistently stored data is appropriately
purged, and potentially to ensure that no network traffic is inadvertently transmitted
outside of the IPsec tunnel.
The TOE mitigates the threat of TSF failure by enforcing the use of self-tests so that the
TOE remains in a known state, and potentially to generate audit records that
allow for potential failures to be diagnosed.
This assumption is satisfied by the environmental objective that ensures
network routes do not exist that allow traffic to be transmitted from the TOE system to its
intended destination without going through the TOE’s IPsec tunnel.
This assumption is satisfied by the environmental objective that ensures the
TOE is not deployed on a system that is vulnerable to loss of physical custody.
This assumption is satisfied by the environmental objective that ensures that
anyone responsible for administering the TOE can be trusted not to misconfigure it,
whether intentionally or not.
5 Security Requirements
This chapter describes the security requirements which have to be fulfilled by the product under evaluation.
Those requirements comprise functional components from Part 2 and assurance components from Part 3 of
[CC].
The following conventions are used for the completion of operations:
Refinement operation (denoted by bold text or strikethrough
text): is used to add details to a requirement (including replacing an assignment
with a more restrictive selection) or to remove part of the requirement that is made irrelevant
through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): is used to select one or more options
provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): is used to assign a
specific value to an unspecified parameter, such as the length of a password. Showing the
value in square brackets indicates assignment.
Iteration operation: is indicated by appending the SFR name with a slash and unique identifier
suggesting the purpose of the operation, e.g. "/EXAMPLE1."
5.1 General Purpose Operating Systems PP
Security Functional Requirements Direction
In a PP-Configuration that includes the GPOS PP, the VPN client is expected to rely on some of the
security functions implemented by the OS as a whole and evaluated against the Base-PP.
In this case, the following sections describe any modifications that the ST author must make to the SFRs
defined in the Base-PP in addition to what is mandated by section 5.5.
5.1.1 Modified SFRs
The SFRs listed in this section are defined in the General Purpose Operating Systems PP and relevant to the secure operation of the TOE.
The OS shall generate asymmetric cryptographic keys in accordance with a specified
cryptographic key generation algorithm:
ECC schemes using “NIST curves” P-256, P-384, and [selection: P-521, no other curves]
that meet the following: FIPSPUB 186-4, “Digital Signature
Standard (DSS),” Appendix B.4, and,
[selection:
RSA schemes using cryptographic key sizes of 2048-bit or greater that meet
the following: FIPSPUB 186-4, “Digital Signature Standard (DSS),”
Appendix B.3,
FFC schemes using cryptographic key sizes of 2048-bit or greater that meet
the following: FIPSPUB 186-4, “Digital Signature Standard (DSS),”
Appendix B.1,
FFC Schemes using Diffie-Hellman group 14 that meet the following: RFC
3526,
FFC Schemes using safe primes that meet the following: ‘NIST Special
Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes,
No other key generation methods
]
and specified cryptographic key sizes [assignment: cryptographic key sizes] that
meet the following: [assignment: list of standards].
Application
Note:
This SFR is functionally identical to what is defined in the GPOS PP except that
ECC key generation with support for P-256 and P-384 has been made mandatory
in support of IPsec due to the mandated support for Diffie-Hellman (DH) groups 19 and 20 in
FCS_IPSEC_EXT.1.8. The ST author must select all key generation schemes used
for key establishment and entity authentication. When key generation is used for
key establishment, the schemes in FCS_CKM.2 and selected cryptographic
protocols must match the selection. When key generation is used for entity
authentication, the public key is expected to be associated with an X.509v3
certificate.
If the OS acts only as a receiver in the RSA key establishment scheme, the OS
does not need to implement RSA key generation.
The OS shall implement functionality to perform cryptographic key
establishment in accordance with a specified key establishment method:
Elliptic curve-based key establishment schemes that meets the following:
NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography,” and
[selection:
RSA-based key establishment schemes that meets the following: RSAESPKCS1-v1_5 as specified in Section 7.2 of RFC 8017, “Public-Key
Cryptography Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.2,
Finite field-based key establishment schemes that meets the following: NIST
Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”,
Key establishment scheme using Diffie-Hellman group 14 that meets the
following: RFC 3526,
No other key establishment schemes
]
that meets the following [assignment: list of standards].
Application
Note:
This SFR is functionally identical to what is defined in the GPOS PP except that elliptic curve cryptography (ECC) key generation with support for P-256 and P-384 has been made mandatory in support of IPsec
due to the mandated support for DH groups 19 and 20 in FCS_IPSEC_EXT.1.8.
The ST author must select all key establishment schemes used for the selected
cryptographic protocols.
The elliptic curves used for the key establishment scheme must correlate with
the curves specified in FCS_CKM.1.1. The domain parameters used for the finite
field-based key establishment scheme are specified by the key generation
according to FCS_CKM.1.1.
FCS_COP.1/1 Cryptographic Operation (Encryption and Decryption)
AES-CCMP-256 (as defined in NIST SP 800-38C and IEEE 802.11ac-2013),
AES-GCMP-256 (as defined in NIST SP 800-38D and IEEE 802.11ac-2013),
No other modes
]
and cryptographic key sizes
[selection: 128-bit, 256-bit].
Application
Note:
This SFR is defined in the GPOS PP as FCS_COP.1(1); the formatting of iteration convention was
updated to be consistent with the PP-Module's conventions.
This SFR is identical to what is defined in the GPOS PP except that support for
CBC and GCM mode is mandatory in order to address the requirements for
FCS_IPSEC_EXT.1. In addition, both 128-bit and 256-bit for key sizes must be
selected in order to meet the requirements for FCS_IPSEC_EXT.1.
5.1.2 Additional SFRs
This section defines additional SFRs that must be added to the TOE boundary in order to implement the functionality in any PP-Configuration where the General Purpose Operating Systems PP is claimed as the Base-PP.
The [selection, choose one of: VPN client, OS] shall store persistent secrets and private keys
when not in use in OS-provided key storage.
Application
Note:
This requirement ensures that persistent secrets (credentials, secret keys) and
private keys are stored securely when not in use. If some secrets or keys are
manipulated by the VPN client and others are manipulated by the OS, then both
of the selections can be specified by the ST author.
5.1.2.2 Identification and Authentication (FIA)
FIA_X509_EXT.3 X.509 Certificate Use and Management
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for IPsec exchanges, and [selection: digital signatures for FPT_TUD_EXT.1, integrity checks for FPT_TST_EXT.1, no additional uses].
When a connection to determine the validity of a certificate cannot be
established, the [selection, choose one of: VPN client, OS] shall [selection, choose one of: allow the administrator to choose whether to accept the certificate in these cases, accept the certificate, not accept the certificate].
Application
Note:
Oftentimes a connection must be established to perform a verification of the
revocation status of a certificate - either to download a certificate revocation list (CRL)
or to use the online certificate status protocol (OCSP) to check revocation status.
The selection is used to describe the behavior in the event that such a connection
cannot be established (for example, due to a network error). The behavior of the
TOE in these cases is described by the second selection. If the TOE has
determined the certificate is valid according to all other rules in FIA_X509_EXT.1,
the behavior indicated in the second selection will determine the validity. The
TOE must not accept the certificate if it fails any of the other validation rules in
FIA_X509_EXT.1. If the administrator-configured option is selected by the ST
Author, the ST author must also make the appropriate selection in
FMT_SMF.1/VPN.
] that is logically
distinct from other communication channels and provides assured identification
of its end points and protection of the channel data from disclosure and
detection of modification of the channel data.
The
[selection, choose one of: VPN client, OS] shall initiate communication via the trusted
channel [for all traffic traversing that connection].
Application
Note:
The intent of the above requirement is to demonstrate that IPsec can be used to
establish remote communications in transport mode, tunnel mode, or both.
The requirement implies that not only are communications protected when they
are initially established, but also on resumption after an outage. It may be the
case that some part of the TOE setup involves manually setting up tunnels to
protect other communication, and if after an outage the TOE attempts to reestablish
the communication automatically with (the necessary) manual
intervention, there may be a window created where an attacker might be able to
gain critical information or compromise a connection.
5.2 Mobile Devices PP
Security Functional Requirements Direction
In a PP-Configuration that includes the MDF PP, the VPN client is expected to rely on some of the
security functions implemented by the OS as a whole and evaluated against the Base-PP.
In this case, the following sections describe any modifications that the ST author must make to the SFRs
defined in the Base-PP in addition to what is mandated by section 5.5.
5.2.1 Modified SFRs
The SFRs listed in this section are defined in the Mobile Devices PP and relevant to the secure operation of the TOE.
The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key
generation algorithm:
ECC schemes using “NIST curves”
[selection: P-256, P-384] and
[selection: P-521, no other curves]
that meet the following: FIPSPUB 186-4, “Digital Signature Standard (DSS),” Appendix B.4;
cryptographic key sizes of 2048-bit or greater that meet
the following: FIPSPUB 186-4, “Digital Signature Standard (DSS),”
Appendix B.1,
Diffie-Hellman group 14 that meet the following: RFC 3526,
“safe-prime” groups that meet the following: ‘NIST Special Publication 800-56A Revision 3,
“Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography
], and,
RSA schemes using cryptographic key sizes of 2048-bit or greater
that meet FIPSPUB 186-4, “Digital Signature Standard (DSS),”
Appendix B.3,
ECC schemes using Curve25519 schemes that meet the following: RFC 7748,
No other key generation methods
].
Application
Note:
This SFR is functionally identical to what is defined in the MDF PP except that
ECC key generation with support for at least one of P-256 and P-384 has been
made mandatory in support of IPsec due to the mandated support for at least
one of DH groups 19 and 20 in FCS_IPSEC_EXT.1.8. Support for “safe-prime”
groups has also been added as a selectable option for DH groups that use finite
field algorithms. Curve25519 schemes remain selectable for their potential use in
satisfying FDP_DAR_EXT.2.2 in the MDF PP; these schemes are not used in
support of IPsec. RSA and ECC support for P-521 remain present as selections
since they may be used by parts of the TOE that are not specifically related to
VPN client functionality.
The TSF shall perform cryptographic key
establishment in accordance with a specified key establishment method:
Elliptic curve-based key establishment schemes that meets the following:
NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography,”
[selection:
Finite field-based key establishment schemes that meets the following: NIST
Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”,
Key establishment scheme using Diffie-Hellman group 14 that meets the
following: RFC 3526, Section 3,
RSA-based key establishment schemes that meet the following:
[selection:
NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key
Establishment Schemes using Integer Factorization Cryptography”,
RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017,
“Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.2
],
no other key establishment schemes
].
Application
Note:
This SFR differs from its definition in the MDF PP by moving elliptic curve-based
key establishment schemes from selectable to mandatory (due to the mandated
support for DH groups 19 and 20 in FCS_IPSEC_EXT.1.8). Finite field and Group
14 selections remain present if groups 14, 15, or 24 are selected in
FCS_IPSEC_EXT.1.8. This PP-Module does not require the use of RSA for any
function but it is present in the selection in case other MDF PP functions require
its use.
AES-CCMP-256 (as defined in NIST SP 800-38C and IEEE 802.11ac-2013),
AES-GCMP-256 (as defined in NIST SP 800-38D and IEEE 802.11ac-2013),
no other modes
]
and cryptographic key sizes 128-bit key sizes and [256-bit key sizes].
Application
Note:
This SFR is identical to what is defined in the MDF PP except that support for
GCM mode and support for 256-bit key sizes are both mandatory in order to
address the requirements for FCS_IPSEC_EXT.1.
provide a VPN client which can protect all IP traffic using IPsec as
defined in the PP-Module for VPN Client
] with the exception of IP traffic needed to manage the VPN connection, and [selection: [assignment:
traffic needed for correct functioning of the TOE], no other traffic] when the VPN is enabled.
Application
Note:
This SFR is identical to its definition in the Base-PP except that the selection item
that requires the TOE to implement its own VPN client is always selected when
the TOE’s conformance claim includes this PP-Module
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for mutually authenticated TLS as defined in the Package for
Transport Layer Security, HTTPS, IPsec in accordance with the PP-Module for
VPN Client,
[selection: mutually authenticated DTLS as defined in the Package
for Transport Layer Security, no other protocols], and
[selection: code signing for system software updates, code signing for mobile applications, code signing for integrity verification, [assignment:
other uses], no additional uses].
When the TSF cannot establish a connection to determine the validity of a
certificate, the TSF shall
[selection, choose one of: allow the administrator to choose whether to accept the certificate in these cases, allow the user to choose whether to accept the certificate in these cases, accept the certificate, not accept the certificate].
Application
Note:
This SFR is identical to what is defined in the MDF PP except that support for
IPsec is mandated. The selection of “no other protocols” is added to address the
case where the TOE only claims support for the protocols that are mandated by
the SFR.
5.2.1.4 Security Management (FMT)
FMT_SMF_EXT.1 Specification of Management Functions
802.11-2012 in accordance with the Extended Package for WLAN Clients
802.1X in accordance with the Extended Package for WLAN Clients
EAP-TLS in accordance with the Extended Package for WLAN Clients
mutually authenticated TLS as defined in the Package for Transport Layer
Security
IPsec in accordance with the PP-Module for VPN Client
and
[selection: mutually authenticated DTLS as defined in the Package for Transport
Layer Security, HTTPS, no other]
protocols to provide a communication channel between itself
and another trusted IT product that is logically distinct from other
communication channels, provides assured identification of its end points,
protects channel data from disclosure, and detects modification of the channel
data.
The TSF shall initiate communication via the trusted channel for wireless access
point connections, administrative communication, configured enterprise
connections, and
[selection: OTA updates, no other connections].
Application
Note:
This SFR is identical to what is defined in the Base-PP except that support for
IPsec is mandated. Additionally, since the Base-PP requires ‘at least one of’ the
selected protocols which previously included IPsec, ‘no other protocols’ is now
available as an option in the selection.
5.3 Application Software PP
Security Functional Requirements Direction
In a PP-Configuration that includes the App PP, the VPN client is expected to rely on some of the security
functions implemented by the OS as a whole and evaluated against the Base-PP. In this
case, the following sections describe any modifications that the ST author must make to the SFRs
defined in the Base-PP in addition to what is mandated by section 5.5.
5.3.1 Modified SFRs
The SFRs listed in this section are defined in the Application Software PP and relevant to the secure operation of the TOE.
] to generate asymmetric cryptographic keys in accordance with a specified
cryptographic key generation algorithm
[ECC schemes] using [“NIST curves” P-256, P-384, and
[selection: P-521, no other curves]] that meet the following: [FIPSPUB 186-4, “Digital Signature
Standard (DSS),” Appendix B.4], and,
[selection:
[FFC schemes] using cryptographic key sizes of [2048-bit or greater] that meet
the following: FIPSPUB 186-4, “Digital Signature Standard (DSS),” Appendix B.1,
[FFC schemes] using Diffie-Hellman group 14 that meet the following: RFC 3526, Section 3,
[FFC Schemes using “safe-prime” groups] that meet the following: ‘NIST Special Publication 800-56A
Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography” and
[selection: RFC 3526, RFC 7919],
[RSA schemes] using cryptographic key sizes of [2048-bit or greater] that
meet the following: [FIPSPUB 186-4, “Digital Signature Standard (DSS),”
Appendix B.3],
no other key generation methods
]
Application
Note:
This SFR is selection-based in the App PP depending on the selection made in
FCS_CKM_EXT.1. Because key generation services (whether implemented by the
TOE or invoked from the platform) are required for IPsec, this SFR is mandatory
for any TOE that claims conformance to this PP-Module.
This SFR is functionally identical to what is defined in the App PP except that ECC
key generation has been made mandatory in support of IPsec due to the
mandated support for DH groups 19, and 20 in FCS_IPSEC_EXT.1.8. RSA remains
present as a selection since it may be used by parts of the TOE that are not
specifically related to VPN client functionality.
The application shall
[selection, choose one of: invoke platform-provided functionality, implement functionality] to perform cryptographic key
establishment in accordance with a specified key establishment method:
[Elliptic curve-based key establishment schemes] that meets the following: [NIST
Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”]; and
[selection:
[Finite field-based key establishment schemes] that meets the following: [NIST
Special Publication 800-56A, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”],
Key establishment scheme using Diffie-Hellman group 14] that meets the
following: [RFC 3526, Section 3],
[FFC Schemes using “safe-prime” groups]that meet the following: ‘NIST Special
Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography” and
[selection: RFC 3526, RFC 7919],
[RSA-based key establishment schemes] that meets the following: RSAES-PKCS1-v1_5 as specified
in Section 7.2 of RFC 8017, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1,
[RSA-based key establishment schemes] that meet the following: [NIST Special
Publication 800-56B, “Recommendation for Pair-Wise Key Establishment
Schemes Using Integer Factorization Cryptography”],
No other schemes
].
Application
Note:
This SFR differs from its definition in the App PP by moving elliptic curve-based
key establishment schemes from selectable to mandatory (due to the mandated
support for DH groups 19 and 20 in FCS_IPSEC_EXT.1.8). It also provides the
ability to claim at least one of NIST SP 800-56A, RFC 3526, or NIST SP 800-56A
rev. 3 “safe-prime” groups for key establishment using finite field cryptography.
The application shall
[selection, choose one of: invoke platform-provided functionality for asymmetric key generation, implement asymmetric key generation].
Application
Note:
This selection differs from its definition in the App PP by
removing the selection for “generate no asymmetric cryptographic keys” for this PP-Module because a VPN Client
TOE will either perform its own key generation or interface with the underlying platform to provide this
service, either of which causes FCS_CKM.1/AK to be claimed.
Application
Note:
This SFR is selection-based in the Base-PP and remains selection-based here because
this PP-Module allows for the possibility that the TSF relies on platform-provided
cryptographic algorithm services for its own implementation of IPsec. However, if
the TSF does claim this SFR to support IPsec, the ST author must select at minimum
both AES-CBC and AES-GCM with both 128-bit and 256-bit key sizes for consistency
with the relevant IPsec claims (FCS_IPSEC_EXT.1.4 requires both 128-bit and 256-bit
AES-GCM and FCS_IPSEC_EXT.1.6 requires both 128-bit and 256-bit AES-CBC).
When the application cannot establish a connection to determine the validity of a
certificate, the TSF shall
[selection, choose one of: allow the administrator to choose whether to accept the certificate in these cases, accept the certificate, not accept the certificate].
Application
Note:
This SFR is identical to what is defined in the App PP except that mandatory
support for IPsec is added. Additionally, because this SFR is selection-based in
the App PP but is mandatory for VPN client usage, the ‘no other protocols’
selection item has been added since it is expected that IPsec is the TOE’s only use
of certificates.
The application shall encrypt all transmitted [sensitive data] using IPsec as specified
in FCS_IPSEC_EXT.1 and
[selection: HTTPS as a client in accordance with FCS_HTTPS_EXT.1/Client, HTTPS as a server in accordance with FCS_HTTPS_EXT.1/Server, HTTPS as a server with mutual authentication in accordance with FCS_HTTPS_EXT.2, TLS as defined in the Functional Package for TLS, DTLS as defined in the Functional Package for TLS, SSH as defined in the Functional Package for Secure Shell, no other protocols]
between itself and another trusted IT product.
Application
Note:
This SFR is identical to what is defined in the App PP except that mandatory support for IPsec is
added, the ST author is forced to select the ‘encrypt all transmitted sensitive data’ option, and
the options for invoking platform-provided functionality have been removed.
Since it is possible that a conformant TOE may not use any encryption protocols other than
IPsec, “no other protocols” is provided as a selectable option in the list of supported protocols.
5.3.2 Additional SFRs
This section defines additional SFRs that must be added to the TOE boundary in order to implement the functionality in any PP-Configuration where the Application Software PP is claimed as the Base-PP.
The
[selection, choose one of: TOE, TOE platform] shall store persistent secrets and private keys
when not in use in platform-provided key storage.
Application
Note:
This requirement ensures that persistent secrets and private keys are stored
securely when not in use. This differs from FCS_STO_EXT.1 in the Base-PP, which
only applies to secure storage of administrative credentials. If some secrets or keys
are manipulated by the TOE and others are manipulated by the platform, then
both of the selections can be specified by the ST author.
The
[selection, choose one of: TOE, TOE platform]
shall zeroize all plaintext secret and private cryptographic keys and CSPs when no longer required.
Application
Note:
Any security related information (such as keys, authentication data, and
passwords) must be zeroized when no longer in use to prevent the disclosure or
modification of security critical data.
The zeroization indicated above applies to each intermediate storage area for
plaintext key or CSP data (i.e., any storage, such as memory buffers, that is included in
the path of such data) upon the transfer of the key or CSP to another location.
In practice, the TOE will not implement all of the functionality associated with
the requirement, since if it performs zeroization at all it will be by invoking
platform interfaces to perform the storage location clear or overwrite function. The
ST author should select "TOE" when, for at least one of the keys needed to meet
the requirements of this PP, the TOE manipulates (reads, writes) the data
identified in the requirement and thus needs to ensure that those data are
cleared. In these cases, it is sufficient for the TOE to invoke the correct
underlying functions of the host to perform the zeroization—it does not imply
that the TOE has to include a kernel-mode memory driver to ensure the data are
zeroized.
In the likely event that some of the data are manipulated by the TOE and other
data are manipulated entirely by the platform, the ST author must select both
options.
5.4 MDM PP
Security Functional Requirements Direction
In a PP-Configuration that includes the MDM PP, the VPN client is expected to rely on some of the
security functions implemented by the OS as a whole and evaluated against the Base-PP.
In this case, the following sections describe any modifications that the ST author must make to the SFRs
defined in the Base-PP in addition to what is mandated by section 5.5.
5.4.1 Modified SFRs
The SFRs listed in this section are defined in the MDM PP and relevant to the secure operation of the TOE.
The TSF shall
[selection, choose one of: invoke platform-provided functionality, implement functionality]
to generate asymmetric cryptographic keys in accordance with a specified cryptographic key
generation algorithm:
ECC schemes using “NIST curves” P-256, P-384, and
[selection: P-521, no other curves]
that meets the following: FIPSPUB 186-4, “Digital Signature Standard (DSS),” Appendix B.4, and
[selection:
RSA schemes using cryptographic key sizes of 2048-bit or greater that meet
FIPSPUB 186-4, "Digital Signature Standard (DSS),” Appendix B.3,
FFC schemes using cryptographic key sizes of 2048-bit or greater that meets
the following: FIPSPUB 186-4, “Digital Signature Standards (DSS),” Appendix B.4,
FFC schemes using “safe-prime” groups that meet the following: ‘NIST
Special Publication 800-56A Revision 3, “ Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography,” and
[selection: RFC 3526, RFC 7919],
FFC schemes using Diffie-Hellman group 14 that meets the following: RFC
3526, Section 3,
No other key generation schemes
].
Application
Note:
This SFR is modified from its definition in the MDM PP by mandating the key
generation algorithms that are required by this PP-Module in support of IPsec due to
the mandated support for DH groups 19 and 20 in FCS_IPSEC_EXT.1.8. Other
selections may be chosen by the ST author as needed for parts of the TOE that are
not specifically related to VPN client functionality.
The TSF shall
[selection, choose one of: invoke platform-provided functionality, implement functionality]
to perform cryptographic key establishment in accordance with a specified key establishment method:
Elliptic curve-based key establishment schemes that meets the following:
NIST Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”
and
[selection:
RSA-based key establishment schemes that meet the following:
RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, “Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.1",
Finite field-based key establishment schemes that meets the following: NIST
Special Publication 800-56A Revision 3, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”,
FFC schemes using "safe-prime" groups that meet the following: 'NIST
Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography" and
[selection: RFC 3526, RFC 7919],
Key establishment scheme using Diffie-Hellman group 14 that meets the
following: RFC 3526, Section 3,
No other schemes
].
Application
Note:
This SFR is modified from its definition in the MDM PP by mandating the key
establishment algorithms that are required by this PP-Module in support of IPsec due
to the mandated support for DH groups 19 and 20 in FCS_IPSEC_EXT.1.8. Other
selections may be chosen by the ST author as needed for parts of the TOE that are
not specifically related to VPN client functionality.
The TSF shall
[selection, choose one of: invoke platform-provided functionality, implement functionality]
perform encryption/decryption in accordance with a specified cryptographic algorithm
Application
Note:
This SFR is defined in the MDM PP as FCS_COP.1(1); the formatting of iteration convention was updated to
be consistent with the PP-Module's conventions.
This SFR is modified from its definition in the Base-PP by mandating support for both
128-bit and 256-bit implementations of AES-CBC (which this PP-Module requires for
the use of IKE and allows for the use of ESP) and AES-GCM (which this PP-Module
requires for the use of ESP and allows for the use of IKE). Other AES modes may be
selected by the ST author as needed to address functions not required by this PP-Module.
Invoke platform-provided functionality to use X.509v3 certificates as defined by
RFC 5280 to support authentication for
[selection: IPsec, HTTPS, TLS, DTLS, SSH, no protocols] and
[selection:
code signing for system software updates,
code signing for integrity verification,
policy signing,
[assignment:
other uses],
no additional uses
],
use X.509v3 certificates as defined by RFC 5280 to support
authentication for
IPsec as specified in the PP-Module for VPN client and
[selection:
HTTPS in accordance with FCS_HTTPS_EXT.1,
TLS as defined in the Package for Transport Layer Security,
DTLS as defined in the Package for Transport Layer Security,
SSH as defined in the Extended Package for Secure Shell,
no other protocols
], and
[selection:
code signing for system software updates,
code signing for integrity verification,
policy signing,
[assignment:
other uses],
no additional uses
]
].
Application
Note:
The PP-Module requires the TOE to implement its own X.509 authentication
mechanism in support of IPsec communications. Other selections may be chosen by
the ST author as needed for parts of the TOE that are not specifically related to VPN
client functionality. The TSF may also rely on a platform-provided mechanism for
uses of X.509 that do not relate to the establishment of trusted communications, as
specified in the original SFR. FIA_X509_EXT.2.2 has not been included here as the PP-Module
does not modify this element.
5.4.1.3 Protection of the TSF (FPT)
FPT_ITT.1/1 Basic Internal TSF Data Transfer Protection
The TSF shall [implement functionality using [IPsec as defined in the PP-Module for
VPN Client]].
Application
Note:
This SFR is defined in the MDM PP as FPT_ITT.1(1); the formatting of iteration convention was updated
to be consistent with the PP-Module's conventions.
When the MDM TOE claims this PP-Module, at least one of its interfaces will implement IPsec
communications. However, this PP-Module does not specify that any one particular interface must be
implemented using IPsec. If the TOE is distributed and uses IPsec to secure communications between its
distributed components, FPT_ITT.1(1) is refined as above.
This SFR is modified from its definition in the Base-PP by mandating that the TSF
implement IPsec communications and by prohibiting the TOE from relying on
platform-provided functionality to implement this.
5.4.1.4 Trusted Path/Channels (FTP)
FTP_ITC.1/1 Inter-TSF Trusted Channel (Authorized IT Entities)
The TSF shall implement functionality using IPsec as defined in the PP-Module
for VPN Client, and
[selection:
SSH as defined in the Extended Package for Secure Shell,
mutually authenticated TLS as defined in the Package for Transport Layer Security,
mutually authenticated DTLS as defined in the Package for Transport Layer Security,
HTTPS in accordance with FCS_HTTPS_EXT.1,
no other protocols
] and
[selection:
invoke platform-provided functionality to use
[selection:
SSH,
mutually authenticated TLS,
mutually authenticated DTLS,
HTTPS
],
not invoke any platform-provided functionality
]
to provide a trusted communication channel between itself and authorized IT
entities supporting the following capabilities: audit server,
[selection: authentication server, [assignment:
other capabilities]]
that is logically distinct from other communication channels and provides assured identification
of its end points and protection of channel data from modification and disclosure.
The TSF shall implement functionality and
[selection, choose one of: invoke platform-provided functionality, not invoke platform-provided functionality]
to permit the MDM Server or other authorized IT entities to initiate communication via the trusted
channel.
The TSF shall implement functionality and
[selection, choose one of: invoke platform-provided functionality, not invoke platform-provided functionality]
to initiate communication via the trusted channel for
[assignment:
list of services for which the TSF is able to initiate communications].
Application
Note:
This SFR is defined in the MDM PP as FTP_ITC.1(1); the formatting of iteration convention was updated to be consistent
with the PP-Module's conventions.
When the MDM TOE claims this PP-Module, at least one of its interfaces will implement IPsec
communications. However, this PP-Module does not specify that any one particular interface must be
implemented using IPsec. If the TOE uses IPsec to secure communications between itself and external
trusted IT entities, FTP_ITC.1(1) is refined as noted by the refinements above.
This SFR is refined from its definition in the Base-PP by mandating that the
“implement functionality” selection be chosen at minimum for IPsec and by
prohibiting the TOE from relying on platform-provided IPsec functionality. Since the
TOE may support multiple trusted channel interfaces, the ST author is given the
option to select other protocols (SSH, TLS, DTLS, HTTPS) either as being implemented
by the TSF or invoked from the platform.
The TSF shall implement functionality using IPsec as defined in the PP-Module
for VPN Client, and
[selection:
TLS as defined in the Package for Transport Layer Security,
HTTPS in accordance with FCS_HTTPS_EXT.1,
SSH as defined in the Extended Package for Secure Shell,
no other protocols
] and
[selection:
invoke platform-provided functionality to use
[selection:
TLS,
HTTPS,
SSH
],
not invoke any platform-provided functionality
]
to provide a trusted communication channel between itself as a
[selection: server, peer]
and remote administrators that is logically distinct from other communication
paths and provides assured identification of its endpoints and protection of the
communicated data from [modification, disclosure].
The TSF shall implement functionality and
[selection, choose one of: invoke platform-provided functionality, not invoke platform-provided functionality]
to permit remote administrators to initiate communication via the trusted channel.
The TSF shall implement functionality and
[selection, choose one of: invoke platform-provided functionality, not invoke platform-provided functionality]
to require the use of the trusted path for [all remote administration actions].
Application
Note:
This SFR is defined in the MDM PP as FTP_TRP.1(1); the formatting of iteration convention was updated to be
consistent with the PP-Module's conventions.
When the MDM TOE claims this PP-Module, at least one of its interfaces will implement IPsec
communications. However, this PP-Module does not specify that any one particular interface must be
implemented using IPsec. If the TOE uses IPsec to secure communications between itself and trusted
remote administrators, FPT_TRP.1(1) is refined as below.
This SFR is refined from its definition in the Base-PP by mandating that the
“implement functionality” selection be chosen at minimum for IPsec and by
prohibiting the TOE from relying on platform-provided IPsec functionality. Since the
TOE may support multiple remote administrative interfaces, the ST author is given
the option to select other protocols (SSH, TLS, HTTPS) either as being implemented
by the TSF or invoked from the platform.
The following section describes the SFRs that must be satisfied by any TOE that claims conformance to this PP-Module.
These SFRs must be claimed regardless of which PP-Configuration is used to define the TOE.
5.5.1 Auditable Events for Mandatory SFRs
Table 2: Auditable Events for Mandatory Requirements
Identity of destination subject. Transport layer protocol, if applicable. Source subject service identifier, if applicable. Non-TOE endpoint of connection (IP address) for both successes and failures.
The TSF shall
[selection, choose one of: invoke platform-provided functionality, implement functionality]
to generate asymmetric cryptographic keys used for IKE peer authentication
in accordance with:
[selection:
FIPSPUB 186-4, “Digital Signature Standard (DSS),” Appendix B.3 for RSA schemes,
FIPSPUB 186-4, “Digital Signature Standard (DSS),” Appendix B.4 for
ECDSA schemes and implementing “NIST curves,” P-256, P-384 and
[selection: P-521, no other curves]
]
and specified cryptographic key sizes [equivalent to, or greater than, a
symmetric key strength of 112 bits] that meet the following:
[assignment:list of standards].
Application
Note:
The keys that are required to be generated by the TOE through this requirement
are intended to be used for the authentication of the VPN entities during the IKE
(either v1 or v2) key exchange. While it is required that the public key be
associated with an identity in an X509v3 certificate, this association is not
required to be performed by the TOE, and instead is expected to be performed by
a Certificate Authority in the OE.
As indicated in FCS_IPSEC_EXT.1, the TOE is required to implement support for
RSA or ECDSA (or both) for authentication.
See NIST Special Publication 800-57, “Recommendation for Key Management”
for information about equivalent key strengths.
The TSF shall implement the IPsec architecture as specified in RFC 4301.
Application
Note:
In the following elements of the FCS_IPSEC_EXT.1 component, it is allowable for some or all of the
individual elements to be implemented by the platform on which the VPN client operates. However, this
is only the case when the platform is within the TOE boundary, as is the case where this PP-Module is
being claimed on top of a general-purpose OS or a mobile device.
When the TOE is a standalone software application, the IPsec functionality must be implemented by the
TSF, though it is permissible for the TSF to invoke cryptographic algorithm services from the TOE
platform to support the TOE’s implementation of IPsec. The TOE may also rely on the TOE platform for
X.509 certificate validation services, though it is the responsibility of the TSF to take the proper action
based on the validation response that is returned.
It is also permissible for the TSF to rely on low-level capabilities of the platform to perform enforcement
and routing functions as a result of the policies the TSF maintains. For example, while the TSF must
provide the capability to implement the Security Policy Database (SPD) abstraction, it is allowed for the TSF to
depend on the platform-provided network stack to perform the low-level packet filtering and
routing actions once the TSF has set up those rules as defined by the SPD.
While enforcement of the IPsec requirements must be implemented by the TSF, it is permissible for the
TSF to receive configuration of the IPsec behavior from an environmental source, most notably a VPN
gateway.
RFC 4301 calls for an IPsec implementation to protect IP traffic through the use
of an SPD. The SPD is used to define how IP packets are
to be handled: PROTECT the packet (e.g., encrypt the packet), BYPASS the IPsec
services (e.g., no encryption), or DISCARD the packet (e.g., drop the packet). The
SPD can be implemented in various ways, including router access control lists,
firewall rulesets, a "traditional" SPD, etc. Regardless of the implementation
details, there is a notion of a "rule" that a packet is "matched" against and a
resulting action that takes place.
While there must be a means to order the rules, a general approach to ordering
is not mandated, as long as the TOE can distinguish the IP packets and apply the
rules accordingly. There may be multiple SPDs (one for each network interface),
but this is not required.
A VPN gateway fully implements the IPsec capability and provides an
administrative interface to establish and populate an SPD. A VPN client is not
required to provide an administrative interface to create or maintain an SPD.
As an alternative, a client may provide an interface that can be used by another
application or network entity, such as a VPN gateway, as a means to establish
and populate the SPD. In either of these cases (the client provides an
administrative interface, or an API), while the client is expected to maintain the
SPD abstraction, it is permitted for the low-level enforcement and routing
activities to be implemented by platform capabilities (e.g., a network driver) as
configured by the client.
The TSF shall implement
[selection: tunnel mode, transport mode].
Application
Note:
If the TOE is used to connect to a VPN gateway for the purposes of establishing a
secure connection to a private network, the ST author is expected to select
tunnel mode. If the TOE uses IPsec to establish an end-to-end connection to
another IPsec VPN Client, the ST author is expected to select transport mode. If
the TOE uses IPsec to establish a connection to a specific endpoint device for the
purpose of secure remote administration, the ST author is expected to select
transport mode.
The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms
[AES-GCM-128, AES-GCM-256 as specified in RFC 4106,
[selection: AES-CBC-128, AES-CBC-256 (both specified by RFC 3602)
together with a Secure Hash Algorithm (SHA)-based HMAC, no other algorithms]].
Application
Note:
If this functionality is configurable, the TSF may be configured by a VPN Gateway
or by an Administrator of the TOE itself.
IKEv1, using Main Mode for Phase I exchanges, as defined in RFCs 2407,
2408, 2409, RFC 4109,
[selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers],
[selection: no other RFCs for hash functions, RFC 4868 for hash functions], and
[selection: support for XAUTH, no support for XAUTH],
IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as
specified in section 2.23), RFC 8784, RFC 8247, and
[selection: no other RFCs for hash functions, RFC 4868 for hash functions]
The TSF shall ensure the encrypted payload in the
[selection: IKEv1, IKEv2]
protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and
[selection: AES-GCM-128 as specified in RFC 5282, AES-GCM-256 as specified in RFC 5282, no other algorithm].
Application
Note:
If this functionality is configurable, the TSF may be configured by a VPN Gateway
or by an Administrator of the TOE itself.
IKEv2 SA lifetimes can be configured by
[selection: an Administrator, a VPN Gateway]
based on
[selection: number of packets/number of bytes, length of time],
IKEv1 SA lifetimes can be configured by
[selection: an Administrator, a VPN Gateway]
based on
[selection: number of packets/number of bytes, length of time],
IKEv1 SA lifetimes are fixed based on
[selection: number of packets/number of bytes, length of time]
].
If length of time is used, it must include at least one option that
is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
Application
Note:
The ST author is afforded a selection based on the version of IKE in their
implementation. There is a further selection within this selection that allows the
ST author to specify which entity is responsible for “configuring” the life of the
security association (SA). An implementation that allows an administrator to configure the client or a
VPN gateway that pushes the SA lifetime down to the client are both acceptable.
As far as SA lifetimes are concerned, the TOE can limit the lifetime based on the
number of bytes transmitted, or the number of packets transmitted. Either
packet-based or volume-based SA lifetimes are acceptable; the ST author makes
the appropriate selection to indicate which type of lifetime limits are supported.
The ST author chooses either the IKEv1 requirements or IKEv2 requirements (or
both, depending on the selection in FCS_IPSEC_EXT.1.5. The IKEv1 requirement
can be accomplished either by providing Authorized Administrator-configurable
lifetimes (with appropriate instructions in documents mandated by AGD_OPE),
or by “hard coding” the limits in the implementation. For IKEv2, there are no
hard-coded limits, but in this case it is required that an administrator be able to
configure the values. In general, instructions for setting the parameters of the
implementation, including lifetime of the SAs, should be included in the
operational guidance generated for AGD_OPE. It is appropriate to refine the
requirement in terms of number of MB or KB instead of number of packets, as long
as the TOE is capable of setting a limit on the amount of traffic that is protected
by the same key (the total volume of all IPsec traffic protected by that key).
The TSF shall ensure that IKE protocols implement DH Groups
19 (256-bit Random ECP), 20 (384-bit Random ECP) according to RFC 5114 and
[selection:
[selection: 14 (2048-bit MODP), 15 (3072-bit MODP), 16 (4096-bit MODP), 17 (6144-bit MODP), 18 (8192-bit MODP)] according to RFC 3526,
[selection: 21 (521-bit Random ECP), 24 (2048-bit MODP with 256-bit POS, no other DH Groups] according to RFC 5114
].
Application
Note:
The selection is used to specify additional DH groups supported. This applies to
IKEv1 and IKEv2 exchanges. It should be noted that if any additional DH groups
are specified, they must comply with the requirements (in terms of the
ephemeral keys that are established) listed in FCS_CKM.1.
Since the implementation may allow different DH groups to be
negotiated for use in forming the SAs, the assignments in FCS_IPSEC_EXT.1.9
and FCS_IPSEC_EXT.1.10 may contain multiple values. For each DH group
supported, the ST author consults Table 2 in 800-57 to determine the “bits of
security” associated with the DH group. Each unique value is then used to fill in
the assignment (for 1.9 they are doubled; for 1.10 they are inserted directly into
the assignment). For example, suppose the implementation supports DH group
14 (2048-bit MODP) and group 20 (ECDH using NIST curve P-384). From Table 2,
the bits of security value for group 14 is 112, and for group 20 it is 192. For
FCS_IPSEC_EXT.1.9, then, the assignment would read “[224, 384]” and for
FCS_IPSEC_EXT.1.10 it would read “[112, 192]” (although in this case the
requirement should probably be refined so that it makes sense mathematically).
The TSF shall generate the secret value x used in the
IKEDH key exchange (“x” in g^x mod p) using the random bit
generator specified in FCS_RBG_EXT.1, and having a length of at least
[assignment:
(one or more) numbers of bits that is at least twice the “bits of
security” value associated with the negotiated DH group as listed in
Table 2 of NIST SP 800-57, Recommendation for Key Management – Part 1:
General] bits.
The TSF shall generate nonces used in IKE exchanges in a manner such that the
probability that a specific nonce value will be repeated during the life a specific
IPsec SA is less than 1 in 2^[assignment:
(one or more) “bits of security” values
associated with the negotiated DH group as listed in Table 2 of NIST
SP 800-57, Recommendation for Key Management – Part 1: General].
The TSF shall ensure that all IKE protocols perform peer authentication using
[selection: RSA, ECDSA]
that use X.509v3 certificates that conform to RFC 4945 and
[selection: Pre-shared keys, Pre-shared Keys transmitted via EAP-TLS, Pre-shared Keys transmitted via EAP-TTLS with mutual authentication, no other method].
Application
Note:
At least one public-key-based Peer Authentication method is required in order to
conform to this PP-Module; one or more of the public key schemes is chosen by
the ST author to reflect what is implemented. The ST author also ensures that
appropriate FCS requirements reflecting the algorithms used (and key
generation capabilities, if provided) are listed to support those methods. Note
that the TSS will elaborate on the way in which these algorithms are to be used
(for example, 2409 specifies three authentication methods using public keys;
each one supported will be described in the TSS).
If any selection with “pre-shared keys” is selected, the selection-based requirement FIA_PSK_EXT.1
must be claimed.
When pre-shared keys are supported for IKEv2, at least one of ‘Pre-shared Keys transmitted via EAP-TLS’ or
‘Pre-shared Keys transmitted via EAP-TTLS’ is selected to indicate client verification using certificates
in a mutually authenticated TLS handshake, and verification of provided PSK protected under the TLS channel. The selection-based SFRFCS_EAP_EXT.1
must also be claimed in this situation.
When Pre-shared Keys are supported for IKEv1, the first selection is claimed to indicate one of the mechanisms
for using PSK described in the RFC.
It is acceptable for different use cases to leverage different selections, if this is the case it must be identified.
The TSF shall not establish an SA if the [selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]
and
[selection: no other reference identifier type, [assignment:
other supported reference identifier types]] contained in a certificate does not match the expected values for the
entity attempting to establish a connection.
Application
Note:
The TOE must support at least one of the following identifier types: IP address,
FQDN, user FQDN, or DN.
In the future, the TOE will be required to support all of these identifier types. The
TOE is expected to support as many IP address formats (IPv4 and IPv6) as IP
versions supported by the TOE in general. The ST author may assign additional
supported identifier types in the second selection.
The TSF shall not establish an SA if the presented identifier does not match the
configured reference identifier of the peer.
Application
Note:
At this time, only the comparison between the presented identifier in the peer’s
certificate and the peer’s reference identifier is mandated by the testing below.
However, in the future, this requirement will address two aspects of the peer
certificate validation: 1) comparison of the peer’s ID payload to the peer’s
certificate which are both presented identifiers, as required by RFC 4945 and 2)
verification that the peer identified by the ID payload and the certificate is the
peer expected by the TOE (per the reference identifier). At that time, the TOE will
be required to demonstrate both aspects (i.e. that the TOE enforces that the
peer’s ID payload matches the peer’s certificate which both match configured
peer reference identifiers).
Excluding the DN identifier type (which is necessarily the Subject DN in the peer
certificate), the TOE may support the identifier in either the Common Name or
Subject Alternative Name (SAN) or both. If both are supported, the preferred
logic is to compare the reference identifier to a presented SAN, and only if the
peer’s certificate does not contain a SAN, to fall back to a comparison against
the Common Name. In the future, the TOE will be required to compare the
reference identifier to the presented identifier in the SAN only, ignoring the
Common Name.
The configuration of the peer reference identifier is addressed by
FMT_SMF.1.1/VPN.
The
[selection: TSF, VPN Gateway] shall be able to ensure by default that the strength of the symmetric algorithm (in terms
of the number of bits in the key) negotiated to protect the
[selection: IKEv1 Phase 1, IKEv2 IKE_SA]
connection is greater than or equal to the strength of the symmetric algorithm
(in terms of the number of bits in the key) negotiated to protect the
[selection: IKEv1 Phase 2, IKEv2 CHILD_SA] connection.
Application
Note:
If this functionality is configurable, the TSF may be configured by a VPN Gateway
or by an Administrator of the TOE itself
The ST author chooses either or both of the IKE selections based on what is
implemented by the TOE. Obviously, the IKE versions chosen should be
consistent not only in this element, but with other choices for other elements in
this component. While it is acceptable for this capability to be configurable, the
default configuration in the evaluated configuration (either "out of the box" or
by configuration guidance in the AGD documentation) must enable this
functionality.
The
[selection, choose one of: TOE, TOE platform]
shall ensure that any previous information content of a resource is made unavailable upon the
[selection: allocation of the resource to, deallocation of the resource from] all objects.
Application
Note:
This requirement ensures, for example, that protocol data units (PDUs) are not
padded with residual information such as cryptographic key material. The ST
author uses the selection to specify when previous information is made
unavailable.
5.5.4 Security Management (FMT)
The TOE is not required to maintain a separate management role. It is, however, required to provide
functionality to configure certain aspects of TOE operation that should not be available to the general
user population. It is possible for the TOE, TOE Platform, or VPN Gateway to provide this functionality.
The client itself has to be configurable - whether it is from the EUD or from a VPN gateway.
FMT_SMF.1/VPN Specification of Management Functions (VPN)
Specify IPsec-capable network devices to use for connections,
Specify client credentials to be used for connections,
Configure the reference identifier of the peer,
[assignment:
any additional management functions]
]
Application
Note:
Several of the management functions defined above correspond to the use cases
of the TOE as follows:
“Specify VPN gateways to use for connections” – Use Case 1
“Specify IPsec VPN Clients to use for connections” – Use Case 2 (specifically
refers to different end points to use for client-to-client connections)
“Specify IPsec-capable network devices to use for connections” – Use Case 3
Selections appropriate for the use cases supported by the TOE should be
claimed. "Client credentials" will include the client certificate used for IPsec
authentication, and may also include a PSK.
For TOEs that support only IP address and FQDN identifier types, configuration
of the reference identifier may be the same as configuration of the peer’s name
for the purposes of connection.
If there are additional management functions performed by the TOE (including
those specified in FCS_IPSEC_EXT.1), they should be added in the assignment.
The
[selection, choose one of: TOE, TOE platform]
shall run a suite of self tests during initial start-up (on power on) to demonstrate the correct
operation of the TSF.
The
[selection, choose one of: TOE, TOE platform]
shall provide the capability to verify the integrity of stored TSF executable code when it is loaded
for execution through the use of the
[assignment:
cryptographic services provided either by the portion
of the TOE described by the Base-PP or by the OE].
Application
Note:
While the TOE is typically a software package running in the IT Environment, it is
still capable of performing the self-test activities required above. It should be
understood, however, that there is a significant dependency on the host
environment in assessing the assurance provided by the tests mentioned above
(meaning that if the host environment is compromised, the self-tests will not be
meaningful).
Cryptographic verification of the integrity is required, but the method by which
this can be accomplished is specified in the ST in the assignment. The ST author
will fill in the assignment with references to the cryptographic functions used to
perform the integrity checks; this will include hashing and may potentially
include digital signatures signed using X.509 certificates. If the TSF provides the
cryptographic services used to verify updates, all relevant FCS_COP requirements
will be identified in the assignment by the ST author.
5.6 TOE Security Functional Requirements Rationale
The following rationale provides justification for each security objective for the TOE,
showing that the SFRs are suitable to meet and achieve the security objectives:
This SFR supports the objective by requiring the
TOE’s implementation of IPsec to include requirements for how the remote VPN gateway or
peer is authenticated.
This SFR supports the objective by optionally defining the TOE's support for a platform-based biometric mechanism to use as an authentication mechanism.
This SFR supports the objective by optionally specifying whether the TOE generates its own pre-shared keys used for authentication or accept them from an external source.
This SFR supports the objective by requiring the TOE
to implement key generation using certain methods or to support invoking this function from its OS
platform.
This SFR supports the objective by requiring the TOE
to implement key establishment using certain methods or to support invoking this function from its
OS platform.
This SFR supports the objective by requiring the TOE
to specify whether it implements its own cryptographic primitives or invokes platform
cryptographic services for these functions.
This SFR supports the objective by requiring the TOE
to implement key generation using certain methods or to support invoking this function from its OS
platform.
This SFR supports the objective by requiring the TOE
to implement key establishment using certain methods or to support invoking this function from its
OS platform.
This SFR supports the objective by requiring that the
TOE implement symmetric encryption and decryption using certain methods or invoke platform
functionality that provides this capability.
If the MDM TOE includes a claim of this PP-Module
to support protection of communications between distributed TOE components, this SFR supports the
objective by requiring the TOE to support the use of IPsec for that interface.
If the MDM TOE includes a claim of this PP-Module
to support protection of communications between the TOE and one or more trusted external IT entities,
this SFR supports the objective by requiring the TOE to support the use of IPsec for that
interface.
If the MDM TOE includes a claim of this PP-Module
to support protection of communications between remote administrators and the TOE, this SFR
supports the objective by requiring the TOE to support the use of IPsec for that interface.
This SFR supports the objective by optionally
requiring the TOE to prohibit split-tunneling so that network traffic cannot be transmitted outside of an
established IPsec tunnel.
This SFR supports the objective by optionally
requiring the TOE to prohibit transmission of packet data aside from those packets needed to perform multifactor authentication.
5.7 TOE Security Assurance Requirements
This PP-Module does not define any SARs beyond those defined within the Base-PPs to which it can
claim conformance. It is important to note that a TOE that is evaluated against this PP-Module is
inherently evaluated against the
General Purpose Operating Systems PP, Mobile Devices PP, Application Software PP, and MDM PP
as well.
These PPs include a
number of EAs associated with both Security Functional Requirements (SFRs) and SARs. Additionally, this
PP-Module includes a number of SFR-based EAs that similarly refine the SARs of the Base-PPs.
The
evaluation laboratory will evaluate the TOE against the chosen Base-PP and supplement that evaluation
with the necessary SFRs that are taken from this PP-Module.
6 Consistency Rationale
6.1
Protection Profile for General Purpose Operating Systems
6.1.1
Consistency of TOE Type
If this PP-Module is used to extend the GPOS PP, the TOE type for the overall TOE is still a
general-purpose OS. The TOE boundary is simply extended to include VPN client functionality that
is built into the OS so that additional security functionality is claimed within the scope of
the TOE.
6.1.2
Consistency of Security Problem Definition
The threats and assumptions defined by this PP-Module (see sections 3.1 and 3.2) supplement those
defined in the GPOS PP as follows:
The threat of an attacker gaining access to a network interface or data
that is transmitted over it is consistent with the T.NETWORK_ATTACK and T.NETWORK_EAVESDROP threats in the GPOS PP.
The threat of a misconfigured VPN client is consistent with the
T.NETWORK_ATTACK and T.NETWORK_EAVESDROP threats on the GPOS PP because misconfiguration could allow VPN traffic to be subjected
unexpectedly to unauthorized modification or disclosure..
The A.NO_TOE_BYPASS assumption assumes that the OE is configured in such a manner that the only network route to the
protected network is through the TOE. This does not conflict with
the GPOS PP because the GPOS PP makes no assumptions about the network architecture in which the TOE is deployed.
The assumption that physical security is provided by the environment is
not explicitly stated in the GPOS PP but is consistent with the A.PLATFORM assumption defined in the GPOS PP, which expects the computing
platform to be trusted.
The assumption that personnel responsible for the TOE’s configuration are
trusted to follow the guidance is consistent with the A.PROPER_ADMIN
defined in the GPOS PP.
6.1.3
Consistency of Objectives
The security objectives defined by this PP-Module (see sections 4.1 and 4.2) supplement those defined
in the GPOS PP as follows:
The objectives for the TOEs are consistent with the General Purpose Operating Systems PP based on the following rationale:
This objective is consistent with the O.PROTECTED_COMMS objective of the
GPOS PP, which also expects that trusted remote channels will enforce
authentication of remote endpoints.
This objective is consistent with the O.PROTECTED_COMMS objective of the
GPOS PP, which also expects that secure cryptographic functions are used to
implement trusted communications.
This objective is consistent with the O.INTEGRITY objective of the GPOS PP,
which expects a conformant TOE to implement measures to maintain its
own integrity.
This objective is consistent with the O.PROTECTED_STORAGE objective of
the GPOS PP, which ensures that sensitive data is not disclosed without
authorization.
The objectives for the TOE's OE are consistent with the General Purpose Operating Systems PP based on the following rationale:
The expectation of trusted configuration is consistent with OE.PROPER_USER
and OE.PROPER_ADMIN in the GPOS PP.
6.1.4
Consistency of Requirements
This PP-Module identifies several SFRs from the
General Purpose Operating Systems PP that are needed to support
Virtual Private Network (VPN) Clients functionality.
This is considered to be consistent because the functionality provided by the
General Purpose Operating Systems PP is being used for its intended purpose.
The PP-Module also identifies a number of modified SFRs from the
General Purpose Operating Systems PP
as well as new SFRs
that are used entirely to provide functionality for
Virtual Private Network (VPN) Clients.
The rationale for why this does not conflict with the claims
defined by the
General Purpose Operating Systems PP are as follows:
The SFR is refined to list an additional AES mode that must be supported to
address VPN client requirements; the use of this mode for VPN connectivity
does not impact the ability of the GPOS to satisfy any of its other security
requirements.
This SFR relates to biometric authentication, which does not conflict with the GPOS PP because it may be a function offered by the
part of the TOE described by the GPOS PP.
This SFR defines an additional cryptographic protocol that is beyond the scope of those defined in the GPOS PP but does not prevent any GPOS PP functionality
from being implemented.
Audit records generated by the VPN client do not interfere with GPOS
functionality. The possibility of the underlying OS platform generating audit
records is consistent with the GPOS PP, which already contains FAU_GEN.1.
The ability to suppress the generation of certain audit records related to
VPN activity does not interfere with the ability of the GPOS to satisfy its
security functionality.
The ability of the VPN client to prevent split tunneling of IPsec traffic
requires it to have hooks into lower-level OS behavior, but there are no
requirements in the GPOS PP that would prevent this functionality from
being supported.
6.2
Protection Profile for Mobile Devices
6.2.1
Consistency of TOE Type
If this PP-Module is used to extend the MDF PP, the TOE type for the overall TOE is still a mobile device.
The TOE boundary is simply extended to include VPN client functionality that is built in to the device’s
software so that additional security functionality is claimed within the scope of the TOE.
6.2.2
Consistency of Security Problem Definition
The threats and assumptions defined by this PP-Module (see sections 3.1 and 3.2) supplement those
defined in the MDF PP as follows:
The threat of an attacker gaining access to a network interface or data
that is transmitted over it is consistent with the T.NETWORK and T.EAVESDROP threats in the MDF PP.
The threat of a misconfigured VPN client is consistent with the
T.NETWORK and T.EAVESDROP threats in the MDF PP because failure to mitigate against misconfiguration makes these threats more significant.
The A.NO_TOE_BYPASS assumption assumes that the OE is configured in such a manner that the only network route
to the protected network is through the TOE. This does not conflict with
the MDF PP because the MDF PP makes no assumptions about the
network architecture in which the TOE is deployed.
The MDF PP includes the A.NOTIFY and A.PRECAUTION assumptions to
mitigate the risk of physical theft of the TOE. This is consistent with the
A.PHYSICAL assumption in this PP-Module because the MDF PP includes
reasonable assumptions about the physical security of the TOE.
This assumption is consistent with the MDF PP because the MDF PP
includes the A.CONFIG assumption which assumes that all security functions are appropriately configured.
6.2.3
Consistency of Objectives
The security objectives defined by this PP-Module (see sections 4.1 and 4.2) supplement those defined
in the MDF PP as follows:
The objectives for the TOEs are consistent with the Mobile Devices PP based on the following rationale:
This objective is consistent with the O.AUTH objective of the MDF PP, which also expects that trusted remote channels will enforce
authentication of remote endpoints.
This objective is consistent with the O.COMMS objective of the
MDF PP, which also expects that secure cryptographic functions are used to implement trusted communications.
This objective is consistent with the O.INTEGRITY objective of the
MDF PP, which expects a conformant TOE to implement measures to maintain its own integrity.
The operational environment of a mobile device cannot guarantee
physical security, but the OE.PRECAUTION objective in the MDF PP
ensures that an appropriate level of physical security is provided.
The expectation of trusted configuration is consistent with
OE.CONFIG in the MDF PP.
6.2.4
Consistency of Requirements
This PP-Module identifies several SFRs from the
Mobile Devices PP that are needed to support
Virtual Private Network (VPN) Clients functionality.
This is considered to be consistent because the functionality provided by the
Mobile Devices PP is being used for its intended purpose.
The PP-Module also identifies a number of modified SFRs from the
Mobile Devices PP
that are used entirely to provide functionality for
Virtual Private Network (VPN) Clients.
The rationale for why this does not conflict with the claims
defined by the
Mobile Devices PP are as follows:
This SFR defines the method of key generation for IKE peer authentication,
which is a function that does not interfere with the functionality defined in
the MDF PP.
This SFR relates to biometric authentication, which does not conflict with the MDF PP because it may be a function offered by the
part of the TOE described by the MDF PP.
This SFR defines an additional cryptographic protocol that is beyond the scope of those defined in the MDF PP but
does not prevent any MDF PP functionality
from being implemented.
Audit records generated by the VPN client do not interfere with MDF
functionality. The possibility of the underlying MDF platform generating
audit records is consistent with the MDF PP, which already contains
FAU_GEN.1.
The ability to suppress the generation of certain VPN client audit records
does not interfere with MDM functionality. The MDF PP already contains
FAU_SEL.1 as an objective SFR which means that this functionality does not
conflict with the expected behavior of a mobile device.
The ability of the VPN client to prevent split tunneling of IPsec traffic
requires it to have hooks into lower-level mobile device behavior, but there
are no requirements in the MDF PP that would prevent this functionality
from being supported.
6.3
Protection Profile for Application Software
6.3.1
Consistency of TOE Type
If this PP-Module is used to extend the App PP, the TOE type for the overall TOE is still a software
application. The TOE boundary is made more specific by defining the TOE as a specific type of
application.
6.3.2
Consistency of Security Problem Definition
The threats and assumptions defined by this PP-Module (see sections 3.1 and 3.2) supplement those
defined in the App PP as follows:
The threat of an attacker gaining access to a network interface or data
that is transmitted over it is consistent with the T.NETWORK_ATTACK and
T.NETWORK_EAVESDROP threats in the App PP.
The A.NO_TOE_BYPASS assumption assumes that the OE is configured in such a manner that the only network route
to the protected network is through the TOE. This does not conflict with
the App PP because the App PP makes no assumptions about the network
architecture in which the TOE is deployed.
The assumption that physical security is provided by the environment is
not explicitly stated in the App PP but is consistent with the A.PLATFORM
assumption defined in the App PP, which expects the computing platform
to be trusted.
The assumption that personnel responsible for the TOE’s configuration are
trusted to follow the guidance is consistent with the A.PROPER_ADMIN
defined in the App PP.
6.3.3
Consistency of Objectives
The security objectives defined by this PP-Module (see sections 4.1 and 4.2) supplement those defined
in the App PP as follows:
The objectives for the TOEs are consistent with the Application Software PP based on the following rationale:
This objective is consistent with the O.PROTECTED_COMMS
objective of the App PP, which also expects that trusted remote
channels will enforce authentication of remote endpoints.
This objective is consistent with the O.PROTECTED_COMMS
objective of the App PP, which also expects that secure
cryptographic functions are used to implement trusted
communications.
This objective is consistent with the O.INTEGRITY objective of the
App PP, which expects a conformant TOE to implement measures
to maintain its own integrity.
This objective is consistent with the O.PROTECTED_STORAGE
objective of the App PP, which ensures that sensitive data is not
disclosed without authorization.
The objectives for the TOE's OE are consistent with the Application Software PP based on the following rationale:
This objective addresses behavior that is out of scope of the App PP
and does not define an environment that is globally applicable to all
software applications.
This is part of satisfying OE.PLATFORM as defined in the App PP
because physical security is required for the underlying platform to
be considered ‘trustworthy’.
The expectation of trusted configuration is consistent with
OE.PROPER_USER and OE.PROPER_ADMIN in the App PP.
6.3.4
Consistency of Requirements
This PP-Module identifies several SFRs from the
Application Software PP that are needed to support
Virtual Private Network (VPN) Clients functionality.
This is considered to be consistent because the functionality provided by the
Application Software PP is being used for its intended purpose.
The PP-Module also identifies a number of modified SFRs from the
Application Software PP
as well as new SFRs
that are used entirely to provide functionality for
Virtual Private Network (VPN) Clients.
The rationale for why this does not conflict with the claims
defined by the
Application Software PP are as follows:
The ST author is instructed to make specific selections at minimum to
address VPN client requirements; the SFR behavior itself is unmodified.
Additionally, this behavior is selection-based in the App PP but is made
mandatory since it is required for VPN client functionality.
The ST author is instructed to make specific selections at minimum to
address VPN client requirements and is modified to include Diffie-Hellman
Group 14 as an additional supported method for key establishment.
The ST author is instructed to make specific selections at minimum to
address VPN client requirements; specifically, since key generation services
are required in some capacity in order to support VPN functionality, the ST
author loses the choice of stating that the application does not have any key
generation functionality. Additionally, this behavior is selection-based in the
App PP but is made mandatory since it is required for VPN client
functionality
The ST author is given guidance to make specific selections if this
selection-based SFR is claimed in support of IPsec functionality. The SFR behavior itself
is unmodified.
This PP-Module is for the VPN Client application and does not maintain any
sensitive data of its own. Therefore, there is no need to protect (through
FTP_DIT_EXT.1.1) VPN-client-specific data.
This PP-Module adds a requirement for key storage, which is new
functionality when compared to the App PP but does not interfere with its existing security functions.
This PP-Module adds a requirement for key destruction, which is new
functionality when compared to the App PP but does not interfere with its
existing security functions.
This SFR defines the method of key generation for IKE peer authentication,
which is a function that does not interfere with the functionality defined in the App PP.
The requirement to protect against re-use of residual data is a property of
the VPN client behavior and does not impact the general application functionality.
This SFR relates to biometric authentication, which does not conflict with the App PP because it may be a function offered by the
OE in which a TOE defined by the App PP is deployed.
This SFR defines an additional cryptographic protocol that is beyond the scope of those defined in the App PP but
does not prevent any App PP functionality
from being implemented.
Audit records generated by the VPN client do not interfere with application
functionality. For cases where auditing is performed by the TOE platform, a
software application is installed on a general-purpose OS or
mobile device, both of which can reasonably be expected to provide audit
functionality.
The ability to suppress the generation of certain audit records related to VPN
activity does not interfere with the ability of the application to satisfy its security functionality.
The ability of the VPN client to prevent split tunneling of IPsec traffic
requires it to have hooks into lower-level OS behavior, but there are no
requirements in the App PP that would prevent this functionality from being supported.
6.4
Protection Profile for MDMs
6.4.1
Consistency of TOE Type
If this PP-Module is used to extend the MDM PP, the TOE type for the overall TOE is still a mobile device
management solution. The TOE boundary is simply extended to include VPN client functionality that is
included with the MDM software so that additional security functionality is claimed within the scope of
the TOE.
6.4.2
Consistency of Security Problem Definition
The threats and assumptions defined by this PP-Module (see sections 3.1 and 3.2) supplement those
defined in the MDM PP as follows:
The threat of an attacker gaining access to a network interface or data
that is transmitted over it is consistent with the T.NETWORK_ATTACK and
T.NETWORK_EAVESDROP threats in the MDM PP.
The threat of a misconfigured VPN client is consistent with the
T.NETWORK_ATTACK and T.NETWORK_EAVESDROP threats in the MDM
PP because failure to mitigate against misconfiguration makes these
threats more significant.
A failure of TSF functionality could compromise the implementation of the
IPsec channel, which would lead to an exploitation of the T.NETWORK_ATTACK threat.
The A.NO_TOE_BYPASS assumption assumes that the OE is configured in such a manner that the only network route
to the protected network is through the TOE. This does not conflict with
the MDM PP because the MDM PP makes no assumptions about the
network architecture in which the TOE is deployed.
The assumption that physical security is provided by the environment is
not explicitly stated in the MDM PP but is consistent with the A.MDM_SERVER_PLATFORM assumption defined in the MDM PP, which
expects the computing platform to be trusted.
The assumption that personnel responsible for the TOE’s configuration are
trusted to follow the guidance is consistent with the A.PROPER_ADMIN
defined in the MDM PP.
6.4.3
Consistency of Objectives
The security objectives defined by this PP-Module (see sections 4.1 and 4.2) supplement those defined
in the MDM PP as follows:
The objectives for the TOEs are consistent with the MDM PP based on the following rationale:
This objective is consistent with the O.DATA_PROTECTION_TRANSIT
objective of the MDM PP, which also expects that trusted remote
channels will enforce authentication of remote endpoints.
This objective is consistent with the O.DATA_PROTECTION_TRANSIT
objective of the MDM PP, which also expects that secure
cryptographic functions are used to implement trusted communications.
This objective is consistent with the O.INTEGRITY objective of the
MDM PP, which expects a conformant TOE to implement measures
to maintain its own integrity.
There are no objectives in the MDM PP that directly relate to this
objective, but it could be considered to support both the
O.ACCOUNTABILITY and O.MANAGEMENT objectives in the MDM PP
by ensuring that stored data cannot be modified through
unauthorized mechanisms that may allow for access control and
logging functions to be bypassed.
The objectives for the TOE's OE are consistent with the MDM PP based on the following rationale:
This is part of satisfying OE.IT_ENTERPRISE as defined in the MDM
PP because provisioning of physical security is a reasonable
expectation for an IT enterprise.
The expectation of trusted configuration is consistent with
OE.PROPER_USER and OE.PROPER_ADMIN in the MDM PP.
6.4.4
Consistency of Requirements
This PP-Module identifies several SFRs from the
MDM PP that are needed to support
Virtual Private Network (VPN) Clients functionality.
This is considered to be consistent because the functionality provided by the
MDM PP is being used for its intended purpose.
The PP-Module also identifies a number of modified SFRs from the
MDM PP
that are used entirely to provide functionality for
Virtual Private Network (VPN) Clients.
The rationale for why this does not conflict with the claims
defined by the
MDM PP are as follows:
When this SFR relates to the PP-Module’s functionality, the ST author is
instructed to make specific selections to implement this behavior using the
VPN client. This is done by forcing the ST author to make specific selections
that are already present in the MDM PP definition of the SFR; no new
behavior is introduced by this.
When this SFR relates to the PP-Module’s functionality, the ST author is
instructed to make specific selections to implement this behavior using the
VPN client at minimum. This is done by forcing the ST author to make a
specific selection that is already present in the MDM PP definition of the SFR
and by removing a selection option; no new behavior is introduced by this.
When this SFR relates to the PP-Module’s functionality, the ST author is
instructed to make specific selections to implement this behavior using the
VPN client at minimum. This is done by forcing the ST author to make a
specific selection that is already present in the MDM PP definition of the SFR
and by removing a selection option; no new behavior is introduced by this.
This SFR defines the method of key generation for IKE peer authentication,
which is a function that does not interfere with the functionality defined in
the MDM PP
This SFR relates to biometric authentication, which does not conflict with the MDM PP
because it may be a function offered by the
part of the TOE described by the MDM PP.
This SFR defines an additional cryptographic protocol that is beyond the scope of those defined
in the MDM PP but does not prevent any MDM PP functionality
from being implemented.
Audit records generated by the VPN client do not interfere with MDM
functionality. The possibility of the MDM as a whole generating audit
records is consistent with the MDM PP, which already contains FAU_GEN.1
The ability to suppress the generation of certain VPN client audit records
does not interfere with MDM functionality. The MDM PP already contains FAU_SEL.1 as an optional SFR which
means that this functionality does not conflict with the expected behavior of an MDM.
The ability of the VPN client to prevent split tunneling of IPsec traffic
requires it to have hooks into lower-level OS behavior, but there are no
requirements in the MDM PP that would prevent this functionality from
being supported.
Appendix A - Optional SFRs
A.1 Strictly Optional Requirements
A.1.1 Auditable Events for Strictly Optional SFRs
Table 4: Auditable Events for Strictly Optional Requirements
The TSF shall not forward packets to the internal network until the IKE/IPsec tunnel has been established,
except those necessary to ensure that the client is authenticated according to FIA_PSK_EXT.1.
The TSFand
[selection, choose one of: TOE platform, no other component]
shall be able to generate an audit record of the following auditable events:
Start-up and shutdown of the audit functions;
All auditable events for the [not specified] level of audit;
All administrative actions;
[Specifically defined auditable events listed in the Auditable Events tables].
Application
Note:
In the case of "a," the audit functions referred to are those provided by the TOE.
For example, in the case that the TOE was a stand-alone executable, auditing
the startup and the shutdown of the TOE itself would be sufficient to meet the
requirements of this clause.
Many auditable aspects of the SFRs included in this document deal with
administrative actions. Item c above requires all administrative actions to be
auditable, so no additional specification of the auditability of these actions is
present in the Auditable Events table. While the TOE itself does not need to
provide the ability to perform I&A for an administrator, this requirement implies
that the TOE possess the capability to audit the events described by the Base-PP
as "administrative actions" (primarily dealing with configuration of the
functionality provided by the TOE).
The auditable events defined in the Auditable Events table are for the SFRs that
are explicitly defined in this PP-Module. For any SFRs that are included as part of
the TOE based on the claimed Base-PP, it is expected that any applicable
auditable events defined for those SFRs in the Base-PP are also claimed as part
of the TSF. These auditable events only apply if the client actually performs these
functions. If the platform performs any of these actions, then the platform is
responsible for performing the auditing, not the TSF
The TSFand
[selection, choose one of: TOE platform, no other component]
shall record within each audit record at least the following information:
Date and time of the event, type of event, subject identity, and the outcome
(success or failure) of the event; and
For each audit event type, based on the auditable event definitions of the
functional components included in the PP-Module/ST, [information
specified in column three of Auditable Events table].
The
[selection, choose one of: TSF, TOE platform]
shall be able to select the set of events to be audited from the set of all auditable events based on
the following attributes:
[event type, [success of auditable security events, failure of auditable security events],
[assignment:
list of additional attributes that audit selectivity is based upon]].
Application
Note:
The intent of this requirement is to identify all criteria that can be selected to
trigger an audit event. This can be configured through an interface on the client
for a user or administrator to invoke, or it could be an interface that the VPN
gateway uses to instruct the client on which events are to be audited. For the ST
author, the assignment is used to list any additional criteria or “none”. The
auditable event types are listed in the Auditable Events table
The intent of the first selection is to allow for the case where the underlying
platform is responsible for some audit log generation functionality.
A.3 Implementation-dependent Requirements
A.3.1 Auditable Events for Implementation-Dependent SFRs
Table 6: Auditable Events for Implementation-dependent Requirements
The TSF shall ensure that all IP traffic (other than IP traffic required to establish
the VPN connection) flow through the IPsec VPN client.
Application
Note:
This requirement is implementation-based on the MDF PP being the Base-PP claimed by the TOE. In this case, this requirement must be claimed.
For all other Base-PPs, this requirement is strictly optional.
This requirement is used when the VPN client is able to enforce the requirement
through its own components. This generally will have to be done through using
hooks provided by the platform such that the TOE is able to ensure that no IP
traffic can flow through other network interfaces.
Appendix B - Selection-based Requirements
B.1 Auditable Events for Selection-based SFRs
Table 7: Auditable Events for Selection-based Requirements
The TSF shall implement
[selection: EAP-TLS protocol as specified in RFC 5216, EAP-TTLS as specified in RFC 5881]
as updated by RFC 8996 with TLS implemented using mutual authentication in accordance with the TLS functional package.
The TSF shall support peer authentication using certificates and
[selection: PSK, HOTP, TOTP, [assignment:
other Authentication-verification protocols], no other authentication]
as updated by RFC 8996 with TLS implemented using mutual authentication in accordance with the TLS functional package.
The TSF shall use the MSK from the
[selection: EAP-TLS, EAP-TTLS] response as the IKEv2 shared secret in the authentication payload.
B.3 Identification and Authentication (FIA)
The TOE may support pre-shared keys for use in the IPsec protocol, and may use pre-shared keys in other protocols as well.
PSK in the context of this document refer to generated values, memorized values subject to conditioning, one-time passwords,
and combinations of the above as described in FIA_PSK_EXT.1.2.
The TSF shall support HMAC-Based One-Time Password authentication (HOTP) in accordance with RFC 4226
to authenticate the user before establishing VPN connection.
The TSF shall use
[selection: SHA-1, SHA-256, SHA-384, SHA-512] with key sizes
[assignment:
key size (in bits) used in HMAC] and message digest sizes
[selection: 160, 256, 384, 512] to derive an HOTP hash from the HOTP seed and counter.
throttle invalid requests to
[selection: administrator configurable value, [assignment:
value less than 10]] per minute,
lock the associated account after
[selection: administrator configurable value, [assignment:
value less than 10]] failed attempts until
[selection: an administrator unlocks the account, a configurable time period]
The TSF shall not verify HOTP attempts outside of the counter look ahead window of
[selection: a configurable value, [assignment:
a value less than or equal to 3]] for resynchronization.
The TSF shall increment the counter after each successful authentication.
Application
Note:
The selection FIA_HOTP_EXT.1.4 must be consistent with the key size specified for the size of the keys used in conjunction with the keyed-hash
message authentication.
In FIA_HOTP_EXT.1.5 the ST author may either provide a configurable character length of at least 6 or a preset size between 6 and 10.
In FIA_HOTP_EXT.1.6 the ST may select throttle requests, account lockout, or both.
The HOTP seed and all derived values are considered secret keys for purposes of protection.
This requirement is selection-dependent on FIA_PSK_EXT.4.
FIA_PSK_EXT.1 Pre-Shared Key Composition
The inclusion of this selection-based component depends upon selection in
FCS_IPSEC_EXT.1.11.
The TSF shall be able to accept the following as pre-shared keys:
[selection: generated bit-based, password-based, HMAC-based one-time password, time-based one-time password, combination of a generated bit-based and HMAC-based one-time password, combination of a generated bit-based and time-based one-time password, combination of a password-based and HMAC-based one-time password, combination of a password-based and time-based one-time password] keys.
Application
Note:
FIA_PSK_EXT.1 includes the options for MFA solutions.
If any selection including "generated bit-based" is chosen, then FIA_PSK_EXT.2 must be included.
If any selection including Password-based keys is chosen, then FIA_PSK_EXT.3 must be included.
If any selection including HMAC-based one-time password keys is chosen, then FIA_PSK_EXT.4 must be included.
If any selection including time-based one-time password is chosen, then FIA_PSK_EXT.5 must be included.
Authentication options may vary between use cases, the VPN may support different options for peer to peer than for
client to gateway. If this is the case the applicable selections shall be mapped to their use cases.
The first four selections are for single factor authentication options, the last four selections are for multifactor authentication options.
FIA_PSK_EXT.2 Generated Pre-Shared Keys
The inclusion of this selection-based component depends upon selection in
FIA_PSK_EXT.1.2.
The TSF shall allow PSKs to be composed of any combination of upper case characters,
lower case characters, numbers, and the following special characters: "!", "@", "#", "$", "%", "^", "&", "*", "(", and ")", and
[selection: [assignment:
other supported special characters], no other characters]
The TSF shall perform Password-based Key Derivation Functions in accordance with a specified cryptographic algorithm HMAC-[selection: SHA-256, SHA-384, SHA-512], with
[assignment:
positive integer of 4096 or more] iterations, and output cryptographic key sizes
[selection: 128, 256] that meet the following: [NIST SP 800-132].
The TSF shall not accept PSKs less than
[selection: a value settable by the administrator, [assignment:
minimum PSK length accepted by the TOE, must be >= 6]] and greater than the maximum PSK length defined in FIA_PSK_EXT.3.1.
The TSF shall
[selection: provide a password strength meter, check the password against a denylist, perform no action to assist the user in choosing a strong password].
Application
Note:
For FIA_PSK_EXT.3.1, the ST author assigns the maximum size of the PSK it supports; it must support at least 64 characters or a length defined by the platform.
For FIA_PSK_EXT.3.2, the ST author assigns any other supported characters; if there are no other supported characters, they should select
"no other characters."
For FIA_PSK_EXT.3.3, the ST author selects the parameters based on the PBKDF used by the TSF.
For FIA_PSK_EXT.3.4 If the minimum length is settable, then the ST author chooses "a value settable by the administrator." If the minimum length is not settable,
the ST author fills in the assignment with the minimum length the PSK must be. This requirement is to ensure bounds work properly.
For FIA_PSK_EXT.3.7, the ST author may select one, both, or neither of the functions in alignment with NIST SP 800-63b.
This requirement is selection-dependent on FIA_PSK_EXT.1.
FIA_PSK_EXT.4 HMAC-Based One-Time Password Pre-shared Keys Support
The inclusion of this selection-based component depends upon selection in
FIA_PSK_EXT.1.2.
The TSF shall [selection, choose one of: verify the HOTP, verify the HOTP via an external authentication server] before establishing an incoming connection.
Application
Note:
If "verify the HOTP..." is selected, then FIA_HOTP_EXT.1 must be included.
This requirement is selection-dependent on FIA_PSK_EXT.1
The selection "verify the HOTP via an external authentication server" is intended to cover the case where the TOE is not doing the verifying,
such as if the when the VPN GW or an authentication server fulfills that function. If a client supports this setup for a peer
to peer use case then the "verify the HOTP" selection may be included.
FIA_PSK_EXT.5 Time-Based One-Time Password Pre-shared Keys Support
The inclusion of this selection-based component depends upon selection in
FIA_PSK_EXT.1.2.
The TSF shall
[selection, choose one of: verify the TOTP, verify the TOTP via an external authentication server] before establishing an incoming connection.
Application
Note:
If verify the TOTP is selected then FIA_TOTP_EXT.1 must be included.
The selection "verify the TOTP via an external authentication server" is intended to cover the case where the TOE is not doing the verifying,
such as if the when the VPN GW or an authentication server fulfills that function. If a client supports this setup for a peer to peer use case then the
"verify the TOTP" selection may be included.
The TSF shall support Time-Based One-Time Password (TOTP) authentication in accordance with RFC 6238
to authenticate the user before establishing VPN connection.
The TSF shall use
[selection: SHA-1, SHA-256, SHA-384, SHA-512] with key sizes
[assignment:
key size (in bits) used in HMAC] and message digest sizes
[selection: 160, 256, 384, 512] to derive a TOTP hash from the TOTP seed and current time provided by NTP.
throttle invalid requests to
[selection: administrator configurable value, [assignment:
value less than 10]] per minute,
lock the associated account after
[selection: administrator configurable value, [assignment:
value less than 10]] failed attempts until
[selection: an administrator unlocks the account, a configurable time period]
The TSF shall not validate a drift of more than
[selection, choose one of: a configurable value, [assignment:
a value less than or equal to 3]] time-steps.
The TSF shall
[selection, choose one of: allow resynchronization by recording time drift within the limit of FIA_TOTP_EXT.1.8, not permit resynchronization].
Application
Note:
The selection FIA_TOTP_EXT.1.4 must be consistent with the key size specified for the size of the keys used in conjunction with the
keyed-hash message authentication.
In FIA_TOTP_EXT.1.5 the ST author may either provide a configurable character length of at least 6 or a preset size between 6 and 10.
In FIA_TOTP_EXT.1.6 the ST author may select throttle requests, account lockout, or both.
The TOTP seed and all derived values are considered secret keys for purposes of protection.
This requirement is selection-dependent on FIA_PSK_EXT.5.
Appendix C - Extended Component Definitions
This appendix contains the definitions for all extended requirements specified in the Module.
C.1 Extended Components Table
All extended components specified in the Module are listed in this table:
Dependencies to:
FCS_CKM.1 Cryptographic Key Generation
FCS_CKM.2 Cryptographic Key Distribution
FCS_COP.1 Cryptographic Operation
FCS_IPSEC_EXT.1.1
The TSF shall implement the IPsec architecture as specified in RFC 4301.
FCS_IPSEC_EXT.1.2
The TSF shall implement
[selection: tunnel mode, transport mode].
FCS_IPSEC_EXT.1.3
The TSF shall have a nominal, final entry in the SPD that matches anything that
is otherwise unmatched, and discards it.
FCS_IPSEC_EXT.1.4
The TSF shall implement the IPsec protocol ESP as defined by RFC 4303 using the cryptographic algorithms
[AES-GCM-128, AES-GCM-256 as specified in RFC 4106,
[selection: AES-CBC-128, AES-CBC-256 (both specified by RFC 3602)
together with a Secure Hash Algorithm (SHA)-based HMAC, no other algorithms]].
IKEv1, using Main Mode for Phase I exchanges, as defined in RFCs 2407,
2408, 2409, RFC 4109,
[selection: no other RFCs for extended sequence numbers, RFC 4304 for extended sequence numbers],
[selection: no other RFCs for hash functions, RFC 4868 for hash functions], and
[selection: support for XAUTH, no support for XAUTH],
IKEv2 as defined in RFC 7296 (with mandatory support for NAT traversal as
specified in section 2.23), RFC 8784, RFC 8247, and
[selection: no other RFCs for hash functions, RFC 4868 for hash functions]
].
FCS_IPSEC_EXT.1.6
The TSF shall ensure the encrypted payload in the
[selection: IKEv1, IKEv2]
protocol uses the cryptographic algorithms AES-CBC-128, AES-CBC-256 as specified in RFC 6379 and
[selection: AES-GCM-128 as specified in RFC 5282, AES-GCM-256 as specified in RFC 5282, no other algorithm].
IKEv2 SA lifetimes can be configured by
[selection: an Administrator, a VPN Gateway]
based on
[selection: number of packets/number of bytes, length of time],
IKEv1 SA lifetimes can be configured by
[selection: an Administrator, a VPN Gateway]
based on
[selection: number of packets/number of bytes, length of time],
IKEv1 SA lifetimes are fixed based on
[selection: number of packets/number of bytes, length of time]
].
If length of time is used, it must include at least one option that
is 24 hours or less for Phase 1 SAs and 8 hours or less for Phase 2 SAs.
FCS_IPSEC_EXT.1.8
The TSF shall ensure that IKE protocols implement DH Groups
19 (256-bit Random ECP), 20 (384-bit Random ECP) according to RFC 5114 and
[selection:
[selection: 14 (2048-bit MODP), 15 (3072-bit MODP), 16 (4096-bit MODP), 17 (6144-bit MODP), 18 (8192-bit MODP)] according to RFC 3526,
[selection: 21 (521-bit Random ECP), 24 (2048-bit MODP with 256-bit POS, no other DH Groups] according to RFC 5114
].
FCS_IPSEC_EXT.1.9
The TSF shall generate the secret value x used in the
IKEDH key exchange (“x” in g^x mod p) using the random bit
generator specified in FCS_RBG_EXT.1, and having a length of at least
[assignment:
(one or more) numbers of bits that is at least twice the “bits of
security” value associated with the negotiated DH group as listed in
Table 2 of NIST SP 800-57, Recommendation for Key Management – Part 1:
General] bits.
FCS_IPSEC_EXT.1.10
The TSF shall generate nonces used in IKE exchanges in a manner such that the
probability that a specific nonce value will be repeated during the life a specific
IPsec SA is less than 1 in 2^[assignment:
(one or more) “bits of security” values
associated with the negotiated DH group as listed in Table 2 of NIST
SP 800-57, Recommendation for Key Management – Part 1: General].
FCS_IPSEC_EXT.1.11
The TSF shall ensure that all IKE protocols perform peer authentication using a
[selection: RSA, ECDSA]
that use X.509v3 certificates that conform to RFC 4945 and
[selection: Pre-shared keys, Pre-shared Keys transmitted via EAP-TLS, Pre-shared Keys transmitted via EAP-TTLS with mutual authentication, no other method].
FCS_IPSEC_EXT.1.12
The TSF shall not establish an SA if the [selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)]
and
[selection: no other reference identifier type, [assignment:
other supported reference identifier types]] contained in a certificate does not match the expected values for the
entity attempting to establish a connection.
FCS_IPSEC_EXT.1.13
The TSF shall not establish an SA if the presented identifier does not match the
configured reference identifier of the peer.
FCS_IPSEC_EXT.1.14
The
[selection: TSF, VPN Gateway] shall be able to ensure by default that the strength of the symmetric algorithm (in terms
of the number of bits in the key) negotiated to protect the
[selection: IKEv1 Phase 1, IKEv2 IKE_SA]
connection is greater than or equal to the strength of the symmetric algorithm
(in terms of the number of bits in the key) negotiated to protect the
[selection: IKEv1 Phase 2, IKEv2 CHILD_SA] connection.
C.2.1.3 FCS_EAP_EXT EAP-TLS
Family Behavior
Components in this family describe the requirements for EAP-TLS.
The TSF shall implement
[selection: EAP-TLS protocol as specified in RFC 5216, EAP-TTLS as specified in RFC 5881]
as updated by RFC 8996 with TLS implemented using mutual authentication in accordance with the TLS functional package.
FCS_EAP_EXT.1.2
The TSF shall generate random values used in the
[selection: EAP-TLS, EAP-TTLS]
exchange using the RBG specified in FCS_RBG_EXT.1.
FCS_EAP_EXT.1.3
The TSF shall support peer authentication using certificates and
[selection: PSK, HOTP, TOTP, [assignment:
other Authentication-verification protocols], no other authentication]
as updated by RFC 8996 with TLS implemented using mutual authentication in accordance with the TLS functional package.
FCS_EAP_EXT.1.4
The TSF shall use the MSK from the
[selection: EAP-TLS, EAP-TTLS] response as the IKEv2 shared secret in the authentication payload.
C.2.2 Identification and Authentication (FIA)
This Module defines the following extended components as part of the
FIA class originally defined by CC Part 2:
C.2.2.1 FIA_X509_EXT X.509 Certificate Use and Management
Family Behavior
Components in this family describe the requirements that pertain to IP traffic and information flow
through the VPN client.
Component Leveling
FIA_X509_EXT.3,
X.509 Certificate Use and Management,
requires the TOE to perform X.509 certificate
authentication and describes the behavior that is followed if the status of the certificate is unknown or
invalid.
Management: FIA_X509_EXT.3
No specific management functions are identified.
Audit: FIA_X509_EXT.3
There are no auditable events foreseen.
FIA_X509_EXT.3 X.509 Certificate Use and Management
Hierarchical to: No other components.
Dependencies to: FIA_X509_EXT.1 X.509 Certificate Validation
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support
authentication for IPsec exchanges, and [selection: digital signatures for FPT_TUD_EXT.1, integrity checks for FPT_TST_EXT.1, no additional uses].
FIA_X509_EXT.3.2
When a connection to determine the validity of a certificate cannot be
established, the [selection, choose one of: VPN client, OS] shall [selection, choose one of: allow the administrator to choose whether to accept the certificate in these cases, accept the certificate, not accept the certificate].
FIA_X509_EXT.3.3
The [selection, choose one of: VPN client, OS] shall not establish an SA if a certificate or
certificate path is deemed invalid.
C.2.2.2 FIA_BMA_EXT Biometric Activation
Family Behavior
Components in this family describe the requirements for biometrics when using the VPN client.
Component Leveling
FIA_BMA_EXT.1,
Biometric Activation,
defines the use of biometrics when using the VPN client.
Management: FIA_BMA_EXT.1
No specific management functions are identified.
Audit: FIA_BMA_EXT.1
No specific audit functions are identified.
FIA_BMA_EXT.1 Biometric Activation
Hierarchical to: No other components.
Dependencies to: No dependencies.
FIA_BMA_EXT.1.1
The TSF shall leverage the platform biometric features to confirm the user before initiating a trusted channel.
Components in this family define requirements for use of HMAC-Based One-Time password authentication, including
generation methods and usage restrictions.
Component Leveling
FIA_HOTP_EXT.1,
HMAC-Based One-Time Password Pre-Shared Keys,
defines the implementation of HOTP.
Dependencies to: FIA_PSK_EXT.4 HMAC-Based One-Time Password Pre-shared Keys Support
FIA_HOTP_EXT.1.1
The TSF shall support HMAC-Based One-Time Password authentication (HOTP) in accordance with RFC 4226
to authenticate the user before establishing VPN connection.
FIA_HOTP_EXT.1.2
The TSF shall generate an HOTP seed according to FCS_RBG_EXT.1 of
[selection: 128, 256] bits.
FIA_HOTP_EXT.1.3
The TSF shall generate a new HOTP seed value for each client.
FIA_HOTP_EXT.1.4
The TSF shall use
[selection: SHA-1, SHA-256, SHA-384, SHA-512] with key sizes
[assignment:
key size (in bits) used in HMAC] and message digest sizes
[selection: 160, 256, 384, 512] to derive an HOTP hash from the HOTP seed and counter.
FIA_HOTP_EXT.1.5
The TSF shall truncate the HOTP hash per FIA_HOTP_EXT.1.4 to create an HOTP of
[selection:
administrator configurable character length of at least 6,
non-configurable character length of
[selection, choose one of: 6, 7, 8, 9, 10]
throttle invalid requests to
[selection: administrator configurable value, [assignment:
value less than 10]] per minute,
lock the associated account after
[selection: administrator configurable value, [assignment:
value less than 10]] failed attempts until
[selection: an administrator unlocks the account, a configurable time period]
].
FIA_HOTP_EXT.1.7
The TSF shall not verify HOTP attempts outside of the counter look ahead window of
[selection: a configurable value, [assignment:
a value less than or equal to 3]] for resynchronization.
FIA_HOTP_EXT.1.8
The TSF shall increment the counter after each successful authentication.
C.2.2.4 FIA_PSK_EXT Pre-Shared Key Composition
Family Behavior
Components in this family describe the requirements for pre-shared keys when implementing IPsec.
Component Leveling
FIA_PSK_EXT.1,
Pre-Shared Key Composition,
defines the use and composition of pre-shared keys used for IPsec.
FIA_PSK_EXT.2,
Generated Pre-Shared Keys,
defines the use and composition of generated pre-shared keys used for IPsec.
FIA_PSK_EXT.3,
Password-Based Pre-Shared Keys,
defines the use and composition of password-based pre-shared keys used for IPsec.
FIA_PSK_EXT.4,
HMAC-Based One-Time Password Pre-shared Keys Support,
defines the use and composition of HOTP pre-shared keys used for IPsec.
FIA_PSK_EXT.5,
Time-Based One-Time Password Pre-shared Keys Support,
defines the use and composition of TOTP pre-shared keys used for IPsec.
The TSF shall be able to use pre-shared keys for IPsec and
[selection: [assignment:
other protocols that use pre-shared keys], no other protocols].
FIA_PSK_EXT.1.2
The TSF shall be able to accept the following as pre-shared keys:
[selection: generated bit-based, password-based, HMAC-based one-time password, time-based one-time password, combination of a generated bit-based and HMAC-based one-time password, combination of a generated bit-based and time-based one-time password, combination of a password-based and HMAC-based one-time password, combination of a password-based and time-based one-time password] keys.
Management: FIA_PSK_EXT.2
No specific management functions are identified.
Audit: FIA_PSK_EXT.2
The following actions should be auditable if FAU_GEN Security Audit Data Generation is included in the
PP/ST:
The TSF shall support a PSK of up to [assignment:
positive integer of 64 or more] characters.
FIA_PSK_EXT.3.2
The TSF shall allow PSKs to be composed of any combination of upper case characters,
lower case characters, numbers, and the following special characters: "!", "@", "#", "$", "%", "^", "&", "*", "(", and ")", and
[selection: [assignment:
other supported special characters], no other characters]
FIA_PSK_EXT.3.3
The TSF shall perform Password-based Key Derivation Functions in accordance with a specified cryptographic algorithm HMAC-[selection: SHA-256, SHA-384, SHA-512], with
[assignment:
positive integer of 4096 or more] iterations, and output cryptographic key sizes
[selection: 128, 256] that meet the following: [NIST SP 800-132].
FIA_PSK_EXT.3.4
The TSF shall not accept PSKs less than
[selection: a value settable by the administrator, [assignment:
minimum PSK length accepted by the TOE, must be >= 6]] and greater than the maximum PSK length defined in FIA_PSK_EXT.3.1.
FIA_PSK_EXT.3.5
The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1 and with entropy of [assignment:
value equal to or greater than 128] bits.
FIA_PSK_EXT.3.6
The TSF shall require the PSK to be entered before every initiated connection.
FIA_PSK_EXT.3.7
The TSF shall
[selection: provide a password strength meter, check the password against a denylist, perform no action to assist the user in choosing a strong password].
Management: FIA_PSK_EXT.4
No specific management functions are identified.
Audit: FIA_PSK_EXT.4
No specific audit functions are identified.
FIA_PSK_EXT.4 HMAC-Based One-Time Password Pre-shared Keys Support
The TSF shall accept and send an HOTP while initiating a VPN connection.
FIA_PSK_EXT.4.2
The TSF shall [selection, choose one of: verify the HOTP, verify the HOTP via an external authentication server] before establishing an incoming connection.
Management: FIA_PSK_EXT.5
No specific management functions are identified.
Audit: FIA_PSK_EXT.5
No specific audit functions are identified.
FIA_PSK_EXT.5 Time-Based One-Time Password Pre-shared Keys Support
The TSF shall accept and send a TOTP while initiating a VPN connection.
FIA_PSK_EXT.5.2
The TSF shall
[selection, choose one of: verify the TOTP, verify the TOTP via an external authentication server] before establishing an incoming connection.
Components in this family define requirements for use of Time-Based One-Time password authentication, including generation
methods and usage restrictions.
Component Leveling
FIA_TOTP_EXT.1,
Time-Based One-Time Password Pre-Shared Keys,
defines the implementation of TOTP.
Dependencies to: FIA_PSK_EXT.5 Time-Based One-Time Password Pre-shared Keys Support
FIA_TOTP_EXT.1.1
The TSF shall support Time-Based One-Time Password (TOTP) authentication in accordance with RFC 6238
to authenticate the user before establishing VPN connection.
FIA_TOTP_EXT.1.2
The TSF shall generate a TOTP seed according to FCS_RBG_EXT.1 of
[selection: 128, 256] bits.
FIA_TOTP_EXT.1.3
The TSF shall generate a new TOTP seed for each client.
FIA_TOTP_EXT.1.4
The TSF shall use
[selection: SHA-1, SHA-256, SHA-384, SHA-512] with key sizes
[assignment:
key size (in bits) used in HMAC] and message digest sizes
[selection: 160, 256, 384, 512] to derive a TOTP hash from the TOTP seed and current time provided by NTP.
FIA_TOTP_EXT.1.5
The TSF shall truncate the TOTP hash per FIA_TOTP_EXT.1.4 to create a TOTP of
[selection:
administrator configurable character length of at least 6,
non-configurable character length of
[selection, choose one of: 6, 7, 8, 9, 10]
throttle invalid requests to
[selection: administrator configurable value, [assignment:
value less than 10]] per minute,
lock the associated account after
[selection: administrator configurable value, [assignment:
value less than 10]] failed attempts until
[selection: an administrator unlocks the account, a configurable time period]
].
FIA_TOTP_EXT.1.7
The TSF shall set a time-step size of
[selection, choose one of: a configurable value, [assignment:
a value less than or equal to 30]] seconds.
FIA_TOTP_EXT.1.8
The TSF shall not validate a drift of more than
[selection, choose one of: a configurable value, [assignment:
a value less than or equal to 3]] time-steps.
FIA_TOTP_EXT.1.9
The TSF shall
[selection, choose one of: allow resynchronization by recording time drift within the limit of FIA_TOTP_EXT.1.8, not permit resynchronization].
C.2.3 Protection of the TSF (FPT)
This Module defines the following extended components as part of the
FPT class originally defined by CC Part 2:
C.2.3.1 FPT_TST_EXT TSF Self-Test
Family Behavior
Components in this family describe requirements for self-test to verify functionality and integrity of the
TOE.
Component Leveling
FPT_TST_EXT.1/VPN,
TSF Self-Test,
requires the TOE to perform power on self-tests to verify its functionality and
the integrity of its stored executable code.
Management: FPT_TST_EXT.1/VPN
No specific management functions are identified.
Audit: FPT_TST_EXT.1/VPN
There are no auditable events foreseen.
FPT_TST_EXT.1/VPN TSF Self-Test
Hierarchical to: No other components.
Dependencies to: No dependencies.
FPT_TST_EXT.1.1/VPN
The
[selection, choose one of: TOE, TOE platform]
shall run a suite of self tests during initial start-up (on power on) to demonstrate the correct
operation of the TSF.
FPT_TST_EXT.1.2/VPN
The
[selection, choose one of: TOE, TOE platform]
shall provide the capability to verify the integrity of stored TSF executable code when it is loaded
for execution through the use of the
[assignment:
cryptographic services provided either by the portion
of the TOE described by the Base-PP or by the OE].
C.2.4 Packet Filtering (FPF)
This class contains families that describe packet filtering behavior. Packet filtering refers to the notion that
network traffic that is transmitted “through” the TOE (i.e. the source and destination of the traffic is not
the TOE but the TOE is on the routing path between these two entities) can be treated differently by the
TSF based on attributes associated with the traffic. As this class is defined solely to contain an extended
component defined for this PP-Module, it has one family, FPF_MFA_EXT.
The TSF shall not forward packets to the internal network until the IKE/IPsec tunnel has been established,
except those necessary to ensure that the client is authenticated according to FIA_PSK_EXT.1.
C.2.5 User Data Protection (FDP)
This Module defines the following extended components as part of the
FDP class originally defined by CC Part 2:
C.2.5.1 FDP_VPN_EXT Subset Information Flow Control
Family Behavior
Components in this family describe the requirements that pertain to IP traffic and information flow
through the VPN client.
Component Leveling
FDP_VPN_EXT.1,
Split Tunnel Prevention,
requires the TSF to process all IP traffic through its VPN client
functionality.
The TSF shall ensure that all IP traffic (other than IP traffic required to establish
the VPN connection) flow through the IPsec VPN client.
Appendix D - Implicitly Satisfied Requirements
This appendix lists requirements that should be considered satisfied by products
successfully evaluated against this Module. These requirements are not featured
explicitly as SFRs and should not be included in the ST. They are not included as
standalone SFRs because it would increase the time, cost, and complexity of evaluation.
This approach is permitted by [CC] Part 1, 8.2 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of particular
security controls. Evaluation against the PP provides evidence that these controls are present
and have been evaluated.
Table 9: Implicitly Satisfied Requirements
Requirement
Rationale for Satisfaction
FCS_CKM.2 – Cryptographic Key
Distribution, or FCS_COP.1 –
Cryptographic Operation
FCS_CKM.1 (which is defined in this PP-Module as
FCS_CKM.1/VPN) requires one of FCS_CKM.2 or FCS_COP.1 to
be claimed so that the generated keys can serve some
security-relevant purpose. Each of the Base-PPs for this PP-Module
define an iteration of FCS_COP.1 for symmetric
cryptography that is expected to use the IKE keys generated
by FCS_CKM.1/VPN. Therefore, this dependency is satisfied
through requirements defined in the Base-PPs.
FCS_CKM.4 – Cryptographic Key Destruction
FCS_CKM.1 (which is defined in this PP-Module as
FCS_CKM.1/VPN) requires FCS_CKM.4 to be claimed so that
the generated keys are not disclosed through improper or
nonexistent key destruction methods.
Each of the supported Base-PPs except for the App PP define
FCS_CKM_EXT.4 as an extended SFR, which defines key
destruction functionality consistent with FCS_CKM.4, but with
additional details that are specific to the respective
technology types of the Base-PP. When the App PP is the
Base-PP, this PP-Module defines its own instance of
FCS_CKM_EXT.4 to achieve the same purpose. The
dependency on FCS_CKM.4 is considered to be satisfied
through the fact that a compliant TOE will always claim
FCS_CKM_EXT.4, which is intended to satisfy the same
purpose.
FCS_COP.1 – Cryptographic Operation
FCS_IPSEC_EXT.1 has a dependency on FCS_COP.1 because of
the cryptographic operations that are needed in support of
implementing the IPsec protocol. FCS_COP.1 is not defined in
this PP-Module because each of the supported Base-PPs
define iterations of FCS_COP.1 that support the functions
that are relevant to IPsec.
FAU_SEL.1/VPN has a dependency on FMT_MTD.1 to enforce
appropriate access controls on the audit configuration, as this
is TSF data. This SFR is not explicitly defined in any of the
supported Base-PPs but the dependency is implicitly
addressed by each Base-PP in the following manner:
GPOS PP: The GPOS PP implicitly defines the
existence of ‘user’ and ‘administrator’ roles in the
extended SFRs FMT_MOF_EXT.1 and
FMT_SMF_EXT.1. A TOE that conforms to this Base-PP can associate the ability to perform the
functionality defined by FAU_SEL.1/VPN to one or
both of these roles.
MDF PP: The MDF PP implicitly defines the existence
of ‘user,’ ‘administrator,’ and ‘MDM’ roles in the
extended SFRs FMT_MOF_EXT.1 and
FMT_SMF_EXT.1. A TOE that conforms to this Base-PP can associate the ability to perform the
functionality defined by FAU_SEL.1/VPN to one or
more of these roles.
App PP: The App PP does not define the existence of
a separately authenticated management interface;
instead, the App PP assumes that authentication to
the underlying OS platform is sufficient authorization
to access the application’s management functionality.
MDM PP: The MDM PP defines the existence of
management roles in FMT_SMR.1(1). A TOE that
conforms to this Base-PP can associate the ability to
perform the functionality defined by FAU_SEL.1/VPN
to one or more of the roles defined here.
FPT_STM.1 – Reliable Time Stamps
FAU_GEN.1/VPN has a dependency on FPT_STM.1 because
audit records are required to have timestamps that are based
on reliable clock data. All of the supported Base-PPs either
define this requirement explicitly or provide rationale for why
the reader should expect that a reliable clock service should
be present. Depending on the claimed Base-PP, the
dependency is satisfied in the following manner:
GPOS PP: The GPOS PP states that FPT_STM.1 is
implicitly satisfied by the requirements of FAU_GEN.1
since that requirement could not be satisfied if no
clock service was present. Additionally, a clock
service is reasonably assumed to be provided by a
general-purpose OS.
App PP: The App PP assumption A.PLATFORM
assumes that the general-purpose computing
platform on which the TOE is installed is ‘a
trustworthy computing platform.’ System time data is
not explicitly mentioned but a clock service is
reasonably assumed to be provided by a general-purpose computer.
MDM PP: The MDM PP assumption
A.MDM_SERVER_PLATFORM assumes that the
platform on which the TOE is installed will provide
reliable time services.
FPT_STM.1 – Reliable Time Stamps
FAU_GEN.1 has a dependency on FPT_STM.1. While not explicitly stated in the PP, it is assumed
that this will be provided by the underlying hardware platform on which the TOE is installed.
This is because the TOE is installed as a software or firmware product that runs on general-purpose
computing hardware so a hardware clock is assumed to be available.
FPT_STM.1 – Reliable Time Stamps
FIA_X509_EXT.1 has a dependency on FPT_STM.1. While not explicitly stated in the PP, it is assumed that
this will be provided by the underlying hardware platform on which the TOE is installed. This is
because the TOE is installed as a software or firmware product that runs on general-purpose computing
hardware so a hardware clock is assumed to be available.
Appendix E - Entropy Documentation and Assessment
The TOE does not require any additional supplementary information to describe its entropy sources
beyond the requirements outlined in the Base-PPs. As with other Base-PP requirements, the only
additional requirement is that the entropy documentation also applies to the specific VPN client
capabilities of the TOE in addition to the functionality required by the claimed Base-PP.
